Python Routes [LSARC/2009/481 FastTrack timeout 09/17/2009]
On Thu, 2009-09-10 at 14:20 -0700, Mark Carlson wrote: This package delivers the latest version of routes (1.10.3) which works with python versions 2.4 and 2.6. The package name is SUNWpy-routes Please deliver 2 packages, one for 2.4 and one for 2.6 otherwise your package needs to depend on both versions, so installing your package will cause both versions to be installed, even if you only need one of them. The package naming convention we have been using for Python modules is SUNWpython24-foo and SUNWpython26-foo. Laca
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 12:55 AM, Alan Coopersmith Alan.Coopersmith at sun.com wrote: I am sponsoring this fast-track for myself, with a timeout of Sept. 17, and a release binding of patch (though delivery is only planned for OpenSolaris Solaris Next at this time). This case is submitted to PSARC, as the traditional arbiter of the Solaris filesystem layout, but cc'ed to LSARC, as it affects cases that LSARC reviews. ? ? ? ?-Alan Coopersmith- ? ? ? ? ? alan.coopersmith at sun.com ? ? ? ? Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction ? ?1.1. Project/Component Working Name: ? ? ? ? Obsolescence of /usr/X11 ? ?1.2. Name of Document Author/Supplier: ? ? ? ? Author: ?Alan Coopersmith ? ?1.3 ?Date of This Document: ? ? ? ?10 September, 2009 4. Technical Description History: Historically Solaris delivered the X Window System software in the /usr/openwin hierarchy, with subdirs mirroring /usr - /usr/openwin/lib, /usr/openwin/bin, etc. ASARC/1996/268 noted that the differing install locations made it hard for users to compile software written for other platforms, so created symlinks from /usr/lib to /usr/openwin/lib, and /usr/include/X11 to /usr/openwin/include/X11, for the public libraries headers. (It notes From the customers that I have dealt with, they feel like *all* APIs belong in /usr/lib, /usr/include, and that Sun was just annoying and foolish for being different. but it took many years for Sun to take that advice to heart.) PSARC 2004/187 established /usr/X11 as the hierarchy for the X Window System software on Solaris, and began to phase out /usr/openwin. PSARC 2008/405 case declared /usr/openwin as Obsolete and removed the /usr/openwin hierarchy from the filesystem, leaving a symbolic link to /usr/X11 in its place for backwards compatibility. Numerous other ARC cases have established that /usr/bin /usr/lib are now the primary installation location for public binaries libraries on Solaris OpenSolaris, and that subsystem-specific hierarchies are now discouraged for commonly-used software. Change: --- This case declares /usr/X11 as Obsolete and allows any files currently delivered there to be delivered to the equivalent location under /usr. Moves of individual files may be considered ARC Self-Review, with a patch release binding, and not require ARC cases as long as they follow these rules: ?- Symbolic links from the /usr/X11 locations to the /usr locations ? ?must be delivered for any public interfaces. ?- Delivery to the normal Solaris locations, following the guidelines ? ?of the Recommended Installation Locations for Solaris-compatible ? ?Software Components ARC Best Practice document and this case. ? ?Specifically, the major directory mappings will be: ? ?Previous location: ? ? ? ? ? ? ? ? ?New location: ? ? /usr/X11/bin ? ? ? ? ? ? ? ? ? ? ? ?/usr/bin ? ? /usr/X11/demo ? ? ? ? ? ? ? ? ? ? ? /usr/bin ? ? /usr/X11/include ? ? ? ? ? ? ? ? ? ?/usr/include ? ? /usr/X11/lib ? ? ? ? ? ? ? ? ? ? ? ?/usr/lib ? ? /usr/X11/lib/modules ? ? ? ? ? ? ? ?/usr/lib/xorg/modules ? ? /usr/X11/lib/X11/app-defaults ? ? ? /usr/share/X11/app-defaults ? ? /usr/X11/lib/X11/fonts ? ? ? ? ? ? ?/usr/share/fonts ? ? /usr/X11/lib/X11/xkb ? ? ? ? ? ? ? ?/usr/share/X11/xkb ? ? /usr/X11/lib/X11/xserver ? ? ? ? ? ?/usr/lib/xorg ? ? /usr/X11/share ? ? ? ? ? ? ? ? ? ? ?/usr/share ? ? /usr/X11/share/man ? ? ? ? ? ? ? ? ?/usr/share/man A future case may remove the /usr/X11 hierarchy completely, and leave a single /usr/X11 - /usr symlink, as 2008/405 did for /usr/openwin, but there are many dependencies to resolve first. The /etc/X11 directory is not affected by this case, and will remain as-is. Rationale/Discussion: - We've had links from /usr/lib to /usr/X11/lib for the libraries since Solaris 2.6, so they'd be in the default path and not require -L or -R at build time, for easier compiling, so that would just replace the links with the real libraries. The programs and man pages would move into the same directories as gnome and the rest of the system, instead of being off in their own world, and one of the last parts of the system left in a separate subhierarchy of the filesystem. Having a separate /usr/X11R5 or /usr/X11R6 made more sense in the days when those were built and installed from a single source tree, so if you wanted a different version or a customized version, you built the entire window system and replaced the entire directory. ? And when we shipped SPARCstation 1's with 105Mb hard disks, being able to put /usr/openwin on a separate partition (local or remote) was crucial. But today, it just makes X different and harder to find and use. Since the LSB/FHS only allowed /usr/X11R6 as an exception to their everything under /usr, not /usr/foo rule, when
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 1:06 AM, Garrett D'Amore gdamore at sun.com wrote: Once getting past the initial shock (okay, I've lived with /usr/X11 for a *really* long time now!), the case seems straight-forward and obvious. ?+1. ? - Garrett Yes, at first it was a scary feeling. But after having thought about it a few times, it may not be a bad idea. (Therefore my +1) -- %martin
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 1:11 AM, Alan Coopersmith Alan.Coopersmith at sun.com wrote: Merging consolidations? ? By the people who would be doing the work and responsible for maintaining it. ? The criteria here would be Does it make sense? and the answer is clearly no - the cost would be too high, the benefit non-existent. It was only an organizational question. Obviously it makes no sense in this case. I thought of it only because of Moinaks auto-builder (and my own insufficient steps towards that direction a year ago). Not combining consolidations for development purposes, just for allowing external distributors to build _everything_ in one rush, without interaction and during sleep. I still do not understand all aspects of how Sun does this internally. Every consolidation generates packages individually and just delivers them into a spool area? Is there no automated A-to-Z tool, that compiles everything at once and then automatically combines the binary packages into a distro via distro-constructor (or in the past: How was it done for SXCE?). Sorry for being a bit OT. But I saw it as a good moment to ask this. Thanks. -- %martin bochnig
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 1:36 AM, Alan Coopersmith Alan.Coopersmith at sun.com wrote: That would be a multi-day build, and adding X would still leave massive amounts outside (SFW, GNOME, Mozilla, etc.). Of course ) Leave it running over the holidays and use a more distributed/parallel make, than dmake. I still do not understand all aspects of how Sun does this internally. Every consolidation generates packages individually and just delivers them into a spool area? Yes. It just thought for a moment, maybe all gates should migrate to exactly the same build system. And every consolidation could be a pluggable module or that single build workspace, all using the same auto-configuration commands and make, the same spec files and so on. But maybe this would not be worth the effort, to forcefully equalize everything. Huge costs, not much benefit. Is there no automated A-to-Z tool, that compiles everything at once and then automatically combines the binary packages into a distro via distro-constructor (or in the past: How was it done for SXCE?). No. ? SXCE is built by combining the packages each consolidation delivers to the common WOS dock. ? ?OpenSolaris is currently built by converting the SVR4 packages in that dock to IPS packages, with some transformations along the way (the distro-import section of the IPS gate) - after the SXCE builds stop, consolidations will start converting to delivering IPS packages to a common repository. Ok, it is probably the most flexible and efficient way of doing things. Good, thanks for your explanation. -- %martin bochnig
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 1:38 AM, Bart Smaalders bart.smaalders at sun.com wrote: Martin Bochnig wrote: Every consolidation generates packages individually and just delivers them into a spool area? yes. Is there no automated A-to-Z tool, that compiles everything at once and then automatically combines the binary packages into a distro via distro-constructor (or in the past: How was it done for SXCE?). No. Each consolidation has different build infrastructure and procedures; = Bart Yes, exactly. Is this a necessity? Wouldnt it be cheaper if all used the same? That was what I objected to. I am just not 100% sure and I wanted to bring this question onto the table to see your responses. Only for consideration. -%martin
Consolidations (Re: [xwin-discuss] Obsolescence of /usr/X11)
On Fri, Sep 11, 2009 at 3:18 AM, Nicolas Williams Nicolas.Williams at sun.com wrote: On Fri, Sep 11, 2009 at 01:52:25AM +0300, Martin Bochnig wrote: On Fri, Sep 11, 2009 at 1:38 AM, Bart Smaalders bart.smaalders at sun.com wrote: No. Each consolidation has different build infrastructure and procedures; Yes, exactly. Is this a necessity? No, but it's almost certainly how it would end up happening no matter what. Wouldnt it be cheaper if all used the same? Not really. ?Different consolidations have different needs and may work very differently from others. ?Consider Source Jucr (not a consolidation, yet, but it's very much like a consolidation): database- and spec file- driven, with a web front-end. ?That's completely different from ON. ?Making Jucr adhere to ON's build style would defeat Jucr's purpose. ?But ON has no use for Jucr's database- and spec file-driven scheme. ?SFW follows the ON model, with various resulting quirks (you can't really split FOSS builds into commands, libraries, etcetera -- but SFW forces you to sort FOSS into commands, libraries, and so on). ?SFW could be converted to Jucr, someday. ?Java probably has a very different build system. ?Imagine making Java, which is multi-platform, have an ON-style build system (ON only builds on Solaris)! ?And so on, and on. That was what I objected to. I am just not 100% sure and I wanted to bring this question onto the table to see your responses. Only for consideration. Your objection isn't about architecture though. Nico Objection may have been the wrong word. (lost in translation ...) As I said: It was a question. And as for the limitations you mentioned: Thanks for this detailed summary. Although: Different needs could also be addressed by a single system (with corresponding case handling). And specifically: is multi-platform, have an ON-style build system (ON only builds on Solaris)! And so on, and on. If you would drop Studio and would globally switch to gcc, you would not only save lots of RD, but additionally you could relatively easily support cross-compilation (x86/SPARC, also on LinUX etc ... ). But this is another situation again, where Sun spends extra money for ending up in less flexibility. So actually you pay twice. Note: This is not a rant by any means. Just a bit of wondering and a few thoughts attempted to express. %martin
[xwin-discuss] Consolidations (Re: Obsolescence of /usr/X11)
On Fri, Sep 11, 2009 at 4:32 AM, Martin Bochnig martin at martux.org wrote: On Fri, Sep 11, 2009 at 3:18 AM, Nicolas Williams Nicolas.Williams at sun.com wrote: On Fri, Sep 11, 2009 at 01:52:25AM +0300, Martin Bochnig wrote: On Fri, Sep 11, 2009 at 1:38 AM, Bart Smaalders bart.smaalders at sun.com wrote: No. Each consolidation has different build infrastructure and And specifically: is multi-platform, have an ON-style build system (ON only builds on Solaris)! ?And so on, and on. If you would drop Studio and would globally switch to gcc, you would not only save lots of RD, but additionally you could relatively easily support cross-compilation (x86/SPARC, also on LinUX etc ... ). But this is another situation again, where Sun spends extra money for ending up in less flexibility. So actually you pay twice. What was missing - as for SCCS make: In 2007 Joerg Schilling invested the effort of porting it to LinUX: http://www.mail-archive.com/opensolaris-discuss at opensolaris.org/msg16549.html Note: This is not a rant by any means. Just a bit of wondering and a few thoughts attempted to express. %martin ___ xwin-discuss mailing list xwin-discuss at opensolaris.org
Add bootpath into Solaris Sparc BootArchive for iSCSI boot [PSARC/2009/480 Self Review]
Jan Setje-Eilers wrote: Bart Smaalders wrote: Mark Carlson wrote: Such a bootpath is not available from OBP, and also Solaris is unable to make up one for, 1) Different disk drivers, 'sd' or 'ssd' can be attached to an iSCSI disk 2) Different TPGT can be used to access the boot disk which causes different device path Therefore the property 'bootpath' is needed to record the device path which is used to boot/install in last time. The same mechanism is in use to support Solaris UFS boot on x86. Is this really the right model to emulate, given that UFS boot is obsolete? ZFS boot doesn't require this on x86. Encoding the real boot path in a file that's part of the OS image you're trying to boot seems problematic. Correct. My previous comment on this was to ask the proposing team to find a better approach. Storing paths such as this breaks systems as soon as a minor configuration change impacts the path. This is a major issue on x86 that has kept OS images from being as portable as they should, and is really something we want to fix as opposed to broadening the impact as you're proposing. That was my thought as well as soon as I saw this. The Solaris Installer will be responsible to update this file during installation and upgrade. Which installer ? Has the project team got a committment from the team working on the Caiman installer to do this for LiveCD and AI installs ? What kind of upgrade is being discussed here ? What happens it the property isn't present ? There is no deus ex machina available during OpenSolaris upgrade to rummage around, updating secret private config files needed to boot. Is there really no better way to fix this? I'd like to see some more investigation here. Why can't this path be determined on-the-fly? At worst this should require tasting a couple of possible devices at mountroot time. Similar to that to even be able to read the file out of the boot archive means we must have sort of iSCSI device available already right ? For me one of the major benefits of iSCSI boot over NFS diskless boot is that it should be highly portable and there should be much less baked into the image. Given the comments from Bart, Jan and myself I'm very close to derailing this case but for the moment I'll strongly suggest it be put in waiting need spec and that the project team work with the installer and boot teams (in particular I strongly suggest taking advice from Jan for the boot issues). -- Darren J Moffat
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, Sep 11, 2009 at 3:28 AM, Sebastien Roy Sebastien.Roy at sun.com wrote: +1 with one minor question: On Thu, 2009-09-10 at 14:55 -0700, Alan Coopersmith wrote: ? ? Specifically, the major directory mappings will be: ? ? Previous location: ? ? ? ? ? ? ? ? ? ? ? ?New location: ? ? ?/usr/X11/bin ? ? ? ? ? ? ? ? ? ? ?/usr/bin ? ? ?/usr/X11/demo ? ? ? ? ? ? ? ? ? ? /usr/bin Would it make sense to have a /usr/demo/X11? Hi, well, maybe they could do this. But what would you want them to put there? glxgears? xlogo? xeyes? Actually one would expect to find those at their default locations. %m
Python Routes [LSARC/2009/481 FastTrack timeout 09/17/2009]
Hi Danek,
My replies embedded:
-manjunath
Danek Duvall wrote:
Mark Carlson wrote:
Dependencies
SUNWpython {Python core package, already available on opensolaris }
- This is must have dependency.
SUNWcherry-python {Web framework for Python, available on opensolaris }
- Routes can work with other web frameworks as well, but this is what I
have used for testing.
There are no packages SUNWpython or SUNWcherry-python. There are
SUNWPython, SUNWPython26, and SUNWpython-cherrypy. The last of those
is a project-private implementation detail of pkg(5) (PSARC/2008/190), and
hasn't been approved by an ARC to be delivered in the Solaris WOS as a
stand-alone component.
I will list the following dependencies:
SUNWPython at 2.4.4,5.11-0.111:20090508T152730Z
SUNWPython26 at 2.6.1,5.11-0.111:20090508T152901Z
SUNWpython-cherrypy at 3.1.1,5.11-0.111:20090508T163103Z
If the web engine is pluggable, is it appropriate to have a hard dependency
on one of them?
But, routes would not work without some version of python, either
2.4 or 2.6. That is the only hard dependency. CherryPy, is not a
hard dependency.
If you're delivering both Python 2.4 and Python 2.6 modules in the same
package, which version of Python does the package depend on?
Ok, agreed. I will deliver the following two packages:
SUNWpython24-routes
SUNWpython26-routes
Interfaces
==
Man pages are included.
The SUNWpy-routes package is Uncommitted.
The remaining interfaces are Volatile.
Exported Interfaces
---
None
None? At all? If a project exports no interfaces, then there's no
architectural content.
I thought, since we are just exposing modules and classes to a web
framework,
they are not public interfaces...it becomes an active exposed interface if
an instance of a class is created, I thought..
Ok, here are the interfaces or modules exposed to any python web framework:
routes
Provides common classes and functions most users will want access to.
routes.base
Route and Mapper core classes
routes.middleware
Routes WSGI Middleware
routes.threadinglocal
routes.util
Utility functions for use in templates / controllers
Imported Interfaces
---
None
Again, routes imports some modules and classes from Cherrypy...
Again?
Not An Interface
/usr/lib/python2.6/vendor-packages/Routes-1.10.3-py2.6.egg-info/PKG-INFO
/usr/lib/python2.6/vendor-packages/Routes-1.10.3-py2.6.egg-info/SOURCES.txt
/usr/lib/python2.6/vendor-packages/Routes-1.10.3-py2.6.egg-info/dependency.txt
/usr/lib/python2.6/vendor-packages/Routes-1.10.3-py2.6.egg-info/not-zip-safe
/usr/lib/python2.6/vendor-packages/Routes-1.10.3-py2.6.egg-info/top_level.txt
/usr/lib/python2.6/vendor-packages/routes/__init__.py
/usr/lib/python2.6/vendor-packages/routes/base.py
/usr/lib/python2.6/vendor-packages/routes/mapper.py
/usr/lib/python2.6/vendor-packages/routes/middleware.py
/usr/lib/python2.6/vendor-packages/routes/route.py
/usr/lib/python2.6/vendor-packages/routes/threadinglocal.py
/usr/lib/python2.6/vendor-packages/routes/util.py
Everything you're delivering is not an interface?
Danek
Again, I am not sure what is the definition of an interface...what
routes does
is, it provides a set of Modules and classes for programmers to develop
mapping between URLs and actions...for implementing dynamic web
applications..
Please do correct me if I am wrong..
-manjunath
Python Routes [LSARC/2009/481 FastTrack timeout 09/17/2009]
Danek, Thanks for your feedback. One thing, I just installed latest OSOL (2009.06) and it does have cherrypy! And it does appear in the /release repository as well (http://pkg.opensolaris.org/release/en/search.shtml?token=pythonaction=Search). Wonder how it made it to /release without getting ARC approval!? I will however remove it my dependency list. -manjunath Danek Duvall wrote: Manjunath Basappa wrote: I will list the following dependencies: SUNWPython at 2.4.4,5.11-0.111:20090508T152730Z SUNWPython26 at 2.6.1,5.11-0.111:20090508T152901Z SUNWpython-cherrypy at 3.1.1,5.11-0.111:20090508T163103Z Sounds good, though a) I'm not sure what the ARC will think of dependencies specified in OpenSolaris terms and b) cherrypy is still not ARCed in any way, and so not suitable for this project to depend on. If the web engine is pluggable, is it appropriate to have a hard dependency on one of them? But, routes would not work without some version of python, either 2.4 or 2.6. That is the only hard dependency. CherryPy, is not a hard dependency. By hard, I mean that you'll be specifying it in your package dependencies; that the routes packages cannot be installed without having cherrypy installed first. If that's not the case (and it sounds like it's not), then there's no need to list cherrypy as an imported interface. It will simply be used if that's what the routes developer chooses to use. If you're delivering both Python 2.4 and Python 2.6 modules in the same package, which version of Python does the package depend on? Ok, agreed. I will deliver the following two packages: SUNWpython24-routes SUNWpython26-routes Sounds fine to me. I thought, since we are just exposing modules and classes to a web framework, they are not public interfaces...it becomes an active exposed interface if an instance of a class is created, I thought.. An interface needn't be a user interface. It is any interface that a project chooses to expose to the outside world. It can be a commandline, a set of functions, an environment variable -- anything that another project might choose to use. Ok, here are the interfaces or modules exposed to any python web framework: routes Provides common classes and functions most users will want access to. routes.base Route and Mapper core classes routes.middleware Routes WSGI Middleware routes.threadinglocal routes.util Utility functions for use in templates / controllers This sounds like a reasonable list. The full list of functions, classes, and methods should be available in the case directory. The output of pydoc module for each module is sufficient. I don't think anyone will bother reviewing them unless you're planning on making a core part of Solaris depend on this project, but it's good to briefly document what you're planning on integrating. Thanks, Danek
Add bootpath into Solaris Sparc BootArchive for iSCSI boot [PSARC/2009/480 Self Review]
Darren J Moffat wrote: ... suggest it be put in waiting need spec and that the project team work with the installer and boot teams (in particular I strongly suggest taking advice from Jan for the boot issues). Done. -- mark
libxklavier re-integration [PSARC/2009/483 FastTrack timeout 09/18/2009]
Suresh Chandrasekharan wrote: Keyboard switching functionality was tested on Sunrays having Xnewt xserver (derived from Xorg codebase) and found to be working well. Is it safe to assume that Xvnc causes no problems either since it is an Xorg codebase server too ? -- Darren J Moffat
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Alan Coopersmith wrote: Numerous other ARC cases have established that /usr/bin /usr/lib are now the primary installation location for public binaries libraries on Solaris OpenSolaris, and that subsystem-specific hierarchies are now discouraged for commonly-used software. Plus, it's weird to have the base OS and GNOME delivered via /usr, but the middleman X Window System relegated to an obscure path. This project fixes that oddity. No longer a Member, but a big +1 from me. Wonderful to see! -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Sebastien Roy wrote: +1 with one minor question: On Thu, 2009-09-10 at 14:55 -0700, Alan Coopersmith wrote: Specifically, the major directory mappings will be: Previous location: New location: /usr/X11/bin /usr/bin /usr/X11/demo/usr/bin Would it make sense to have a /usr/demo/X11? If we had any software that we really wanted hidden there, yes. Right now, we don't. Most of what was in /usr/openwin/demo already moved to /usr/X11/bin since we got tired of telling users that things were hidden there, or finding that people had redelivered things like xeyes that were hidden there. Right now the only thing in /usr/X11/demo is glxgears, which all other distros ship in a normal bin directory. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
On Fri, 2009-09-11 at 06:45 -0700, Alan Coopersmith wrote: Sebastien Roy wrote: +1 with one minor question: On Thu, 2009-09-10 at 14:55 -0700, Alan Coopersmith wrote: Specifically, the major directory mappings will be: Previous location: New location: /usr/X11/bin /usr/bin /usr/X11/demo /usr/bin Would it make sense to have a /usr/demo/X11? If we had any software that we really wanted hidden there, yes. Right now, we don't. Most of what was in /usr/openwin/demo already moved to /usr/X11/bin since we got tired of telling users that things were hidden there, or finding that people had redelivered things like xeyes that were hidden there. Right now the only thing in /usr/X11/demo is glxgears, which all other distros ship in a normal bin directory. Understood, that's fine with me. -Seb
libxklavier re-integration [PSARC/2009/483 FastTrack timeout 09/18/2009]
libxklavier will work reliably only when X display is local, it is not meant to work with remote x displays (Sunrays act like a local machine with's connected with many displays and keyboards). It can only read the configuration files of the machine in which the keyboard switching program runs, in case of Xvnc which's invariably always run remotely it does not make sense to read the keyboard configuration of the remote machine and apply it locally. (Eventhough it's run in the same machine, the hosting Xserver seems to prevent keyboardgrab and keyboard switching didn't work from Xvnc session.) In our tests with remote Xvnc sessions this does not produce any issues like jumbled input, it's just that keyboard switching failed, session retained the original settings. Thanks, Suresh Darren J Moffat wrote: Suresh Chandrasekharan wrote: Keyboard switching functionality was tested on Sunrays having Xnewt xserver (derived from Xorg codebase) and found to be working well. Is it safe to assume that Xvnc causes no problems either since it is an Xorg codebase server too ?
Consolidations (Re: [xwin-discuss] Obsolescence of /usr/X11)
I disagree on the points about the sun studio compilers. I've seen better binary and optimization results with sun studio than with GCC. I've worked with GCC on other platforms, Power and Alpha.. and needless to say it's a dog. All the development on GCC is really focused on x86 and most optimizations for other platforms come from the vendors. Sun Studio on the other hand has a great tool set and the fact that it is free should make the idea of using GCC dead in my opinion. If anything, just more work around dealing with GCC-isms would help compile and build FOSS apps. However, the bigger issue on that front is that many of those FOSS apps are starting to loose site of the UNIX philosophy of being easily portable between platforms. So even if you use GCC, it may not work. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: Martin Bochnig mar...@martux.org To: Nicolas Williams Nicolas.Williams at sun.com Cc: xwin-discuss at opensolaris.org; Alan Coopersmith Alan.Coopersmith at sun.com; Bart Smaalders Bart.Smaalders at sun.com; LSARC-ext at sun.com; PSARC-ext at sun.com Sent: Thursday, September 10, 2009 8:32:58 PM Subject: Re: Consolidations (Re: [xwin-discuss] Obsolescence of /usr/X11) On Fri, Sep 11, 2009 at 3:18 AM, Nicolas Williams Nicolas.Williams at sun.com wrote: On Fri, Sep 11, 2009 at 01:52:25AM +0300, Martin Bochnig wrote: On Fri, Sep 11, 2009 at 1:38 AM, Bart Smaalders bart.smaalders at sun.com wrote: No. Each consolidation has different build infrastructure and procedures; Yes, exactly. Is this a necessity? No, but it's almost certainly how it would end up happening no matter what. Wouldnt it be cheaper if all used the same? Not really. Different consolidations have different needs and may work very differently from others. Consider Source Jucr (not a consolidation, yet, but it's very much like a consolidation): database- and spec file- driven, with a web front-end. That's completely different from ON. Making Jucr adhere to ON's build style would defeat Jucr's purpose. But ON has no use for Jucr's database- and spec file-driven scheme. SFW follows the ON model, with various resulting quirks (you can't really split FOSS builds into commands, libraries, etcetera -- but SFW forces you to sort FOSS into commands, libraries, and so on). SFW could be converted to Jucr, someday. Java probably has a very different build system. Imagine making Java, which is multi-platform, have an ON-style build system (ON only builds on Solaris)! And so on, and on. That was what I objected to. I am just not 100% sure and I wanted to bring this question onto the table to see your responses. Only for consideration. Your objection isn't about architecture though. Nico Objection may have been the wrong word. (lost in translation ...) As I said: It was a question. And as for the limitations you mentioned: Thanks for this detailed summary. Although: Different needs could also be addressed by a single system (with corresponding case handling). And specifically: is multi-platform, have an ON-style build system (ON only builds on Solaris)! And so on, and on. If you would drop Studio and would globally switch to gcc, you would not only save lots of RD, but additionally you could relatively easily support cross-compilation (x86/SPARC, also on LinUX etc ... ). But this is another situation again, where Sun spends extra money for ending up in less flexibility. So actually you pay twice. Note: This is not a rant by any means. Just a bit of wondering and a few thoughts attempted to express. %martin ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009]
Roland Mainz wrote: Mahesh Siddheshwar wrote: Roland Mainz wrote: Does it make sense to have a |xu_flags| field here for future enhancments ? If future enhancements are needed to extend xuio_t, a new xuio_type can be defined and extended that way. For extensions not specific to xuio, there also exists uio_extflg in the uio_t. Without a particular purpose an additional flag seems unnecessary for zero-copy right now. Right now... yes. But Unix has a little (IMO) ugly tradition of not adding such flag fields and instead swamping the headers with many many variations of one interface over time which could be avoided by use having a flags field as argument (that's a generic issue). [snip] b. Requesting zero-copy buffers #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, caller_context_t *) AFAIK the prototype should have a flags field to allow future changes/extenstions without adding another VOP_*-hook ... Roland, if the extensions/changes are for the purpose of copy reduction/buffer sharing, we don't need to add additional VOP_* routines. The current xuio_t extension is defined just for that. Erm... the idea of having a flags field in |fop_reqzcbuf()| was to allow slight modifications in behaviour - for example in the future there could be flags which describe where (in a NUMA system) the buffer memory resides (e.g. near the calling thread, near a point which is optimal for all consumers, or near the hardware which fills the buffer etc.), whether it should be in the L2 cache or not etc. etc. Roland, I agree with Nico on the drawbacks of adding undefined flags for future use. You make two suggestions: 1) addition of a flag to xuio_t for future use 2) addition of a flag to VOP_REQZCBUF() for future use. It's the project team's opinion that these flags are not needed for this spec, for the following reasons: For 1) the existence of uio_extflg in uio_t and the possibility of extending xuio_t through additional xuio_type's, make an additional 'xu_flags' flag an overhead that can be avoided. For 2) we don't have a specific purpose for the flag right now. If there is a need for additional flags or arguments in future, the VOP routine can be easily extended. As has been done in the recent past with several extensions for existing VOP routines (PSARC 2007/244, 2007/218, 2007/227, 2009/387). The existence of strong type checking for vnode/vfs operations through PSARC 2007/124 make it easier to catch an interface mismatch. Thanks, Mahesh
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]
On Wed, Sep 09, 2009 at 04:02:15PM -0500, Rich.Brown at sun.com wrote: == Introduction/Background == Zero-copy (copy avoidance) is essentially buffer sharing among multiple modules that pass data between the modules. This proposal avoids the data copy in the READ/WRITE path of filesystems, by providing a mechanism to share data buffers between the modules. It is intended to be used by network file sharing services like NFS, CIFS or others. Although the buffer sharing can be achieved through a few different solutions, any such solution must work with File Event Monitors (FEM monitors)[1] installed on the files. The solution must allow the underlying filesystem to maintain any existing file range locking in the filesystem. The proposed solution provides extensions to the existing VOP interface to request and return buffers from a filesystem. The buffers are then used with existing VOP_READ/VOP_WRITE calls with minimal changes. == Proposed Changes == ... == Using the New VOP Interfaces for Zero-copy == VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with VOP_READ() or VOP_WRITE() to implement zero-copy read or write. a. Read In a normal read, the consumer allocates the data buffer and passes it to VOP_READ(). The provider initiates the I/O, and copies the data from its own cache buffer to the consumer supplied buffer. To avoid the copy (initiating a zero-copy read), the consumer first calls VOP_REQZCBUF() to inform the provider to prepare to loan out its cache buffer. It then calls VOP_READ(). After the call returns, the consumer has direct access to the cache buffer loaned out by the provider. After processing the data, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. ... b. Write In a normal write, the consumer allocates the data buffer, loads the data, and passes the buffer to VOP_WRITE(). The provider copies the data from the consumer supplied buffer to its own cache buffer, and starts the I/O. To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to grab a cache buffer from the provider. It loads the data directly to the loaned cache buffer, and calls VOP_WRITE(). After the call returns, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. Just for clarification: this interface only affects pages mapped in the kernel, correct? I'm trying to understand if this is just for reducing the number of in-kernel copies, or if this is a userland - kernel zero-copy interface. Thanks, -j
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]
johansen at sun.com wrote: On Wed, Sep 09, 2009 at 04:02:15PM -0500, Rich.Brown at sun.com wrote: == Introduction/Background == Zero-copy (copy avoidance) is essentially buffer sharing among multiple modules that pass data between the modules. This proposal avoids the data copy in the READ/WRITE path of filesystems, by providing a mechanism to share data buffers between the modules. It is intended to be used by network file sharing services like NFS, CIFS or others. Although the buffer sharing can be achieved through a few different solutions, any such solution must work with File Event Monitors (FEM monitors)[1] installed on the files. The solution must allow the underlying filesystem to maintain any existing file range locking in the filesystem. The proposed solution provides extensions to the existing VOP interface to request and return buffers from a filesystem. The buffers are then used with existing VOP_READ/VOP_WRITE calls with minimal changes. == Proposed Changes == ... == Using the New VOP Interfaces for Zero-copy == VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with VOP_READ() or VOP_WRITE() to implement zero-copy read or write. a. Read In a normal read, the consumer allocates the data buffer and passes it to VOP_READ(). The provider initiates the I/O, and copies the data from its own cache buffer to the consumer supplied buffer. To avoid the copy (initiating a zero-copy read), the consumer first calls VOP_REQZCBUF() to inform the provider to prepare to loan out its cache buffer. It then calls VOP_READ(). After the call returns, the consumer has direct access to the cache buffer loaned out by the provider. After processing the data, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. ... b. Write In a normal write, the consumer allocates the data buffer, loads the data, and passes the buffer to VOP_WRITE(). The provider copies the data from the consumer supplied buffer to its own cache buffer, and starts the I/O. To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to grab a cache buffer from the provider. It loads the data directly to the loaned cache buffer, and calls VOP_WRITE(). After the call returns, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. Just for clarification: this interface only affects pages mapped in the kernel, correct? I'm trying to understand if this is just for reducing the number of in-kernel copies, or if this is a userland - kernel zero-copy interface. That is correct. This interface is to prevent in-kernel copies and allow buffer sharing between kernel modules (that can be used by in-kernel services like NFS or CIFS). The spec does not define any userland - kernel zero-copy interface. Thanks, Mahesh Thanks, -j
Consolidations (Re: [xwin-discuss] Obsolescence of /usr/X11)
Hi, I've seen this as the case with the following types of applications: 1. HPC applications where Sun Studio optimization can help out considerably. This is the same in Linux/x86 shops who use non-gcc compilers for better optimizations. 2. Financial applications that process TB's of data for analysis. Would usually see about 20-30% improvement here. 3. Web Applications and tools. A few years back I use to work for a web hosting company and found that apache, perl, mysql, and qmail worked faster when compiled with Sun Studio. 4. SPEC benchmarks. These benchmarks do perform better with the Sun Studio compiler. Use to run these benchmarks to compare different server models and platforms. Now on a more practical side.. 1. Solaris itself is compiled with Sun Studio. 2. Take something like Quake 3 Arena and compare the performance between it being compiled on Sun Studio vs GCC, you'll see a difference while playing. 3. Just 3 years ago I recompiled all the open source tools (compilers, interpreted languages, xml tools, numerical libraries, etc.) we were using at a investment company. The question was posed if Sun Studio would make faster binaries and libraries. We did tests against some of the key tools and found that at least a 10-20% performance improvement was seen. So from my experience, I've seen a difference since Sun Studio 10 onwards and use it for all the software I compile. I think there is a lot of value in it. Now, I've seen the same kinds of results on other non-x86 platforms where the vendor compiler or a 3rd party compiler performed better than GCC. While it works on many platforms, it is not highly optimized on them. Obviously, Sun Studio is only on Solaris SPARC/x86 and Linux x86. It would be interesting to see Sun Studio on Power to support the OpenSolaris port there. But I don't know how difficult it would be to open source Sun Studio and do something like that. Of course, Sun was wise to buy Forte years ago, which I remember since I was in IT/Ops back then in the bay area. It may not seem like it on the surface, but it was a great investment and helped Sun's development tools and at the end of the day the performance increases in Solaris 9 considerably. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: Martin Bochnig mar...@martux.org To: Octave Orgeron unixconsole at yahoo.com Cc: Nicolas Williams Nicolas.Williams at sun.com; xwin-discuss at opensolaris.org; Alan Coopersmith Alan.Coopersmith at sun.com; Bart Smaalders Bart.Smaalders at sun.com; LSARC-ext at sun.com; PSARC-ext at sun.com Sent: Friday, September 11, 2009 4:13:45 PM Subject: Re: Consolidations (Re: [xwin-discuss] Obsolescence of /usr/X11) On Fri, Sep 11, 2009 at 7:53 PM, Octave Orgeron unixconsole at yahoo.com wrote: I disagree on the points about the sun studio compilers. I've seen better binary and optimization results with sun studio than with GCC. I've worked with GCC on other platforms, Power and Alpha.. and needless to say it's a dog. All the development on GCC is really focused on x86 and most optimizations for other platforms come from the vendors. Sun Studio on the other hand has a great tool set and the fact that it is free should make the idea of using GCC dead in my opinion. If anything, just more work around dealing with GCC-isms would help compile and build FOSS apps. However, the bigger issue on that front is that many of those FOSS apps are starting to loose site of the UNIX philosophy of being easily portable between platforms. So even if you use GCC, it may not work. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave, this was true 20 years ago. Which kind of benchmark did you perform yourself? Yes, also on SPARC? The results might surprise you. But whatever, if nobody believes me, I will prove it. I dont like to fight with / against community fellows. When we have some precise numbers, we can continue our discussion. Until then, regards, %martin
PSARC/2007/596 Packaging contracted consolidation private files for SFW
The RBridges project will be including the files listed below from the ON consolidation to existing packages SUNWhea and SUNWcslr to satisfy the case contract with the SFW consolidation. They remain contracted consolidation private and will still require a contract from consumers before use. Additions to SUNWhea: usr/include/libdladm.h usr/include/libdllink.h usr/include/libdlvlan.h usr/include/libdlbridge.h usr/include/uid_stp.h usr/include/sys/dld.h usr/include/sys/dls_mgmt.h usr/include/sys/mac.h usr/include/sys/mac_flow.h Additions to SUNWcslr: lib/libdladm.so=./libdladm.so.1 lib/llib-ldladm.ln lib/amd64/libdladm.so=./libdladm.so.1 lib/amd64/llib-ldladm.ln lib/sparcv9/libdladm.so=./libdladm.so.1 lib/sparcv9/llib-ldladm.ln
Crypt-DES Perl Module [LSARC/2009/484 FastTrack timeout 09/28/3009]
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Crypt-DES Perl Module 1.2. Name of Document Author/Supplier: Author: Spoorthy Shankarmurthy 1.3 Date of This Document: 11 September, 2009 4. Technical Description Summary === Crypt::DES is an XS-based DES implimentation for Perl The latest version of Crypt-DES is 2.05 and will be installed as SUNWperl-crypt-des package. Dependencies NONE Interfaces == Man pages are included. The SUNWperl-crypt-des package is Uncommitted. The remaining interfaces are Volatile. Exported Interfaces --- /usr/perl5/vendor_perl/5.8.4/Crypt/DES.pm - Perl module file required by the package /usr/perl5/vendor_perl/5.8.4/Crypt/DES.xs /usr/perl5/5.8.4/man/man3/Crypt::DES.3 Man pages for the package Crypt-DES Imported Interfaces --- Digest::MD5 -- Perl Module Not An Interface /usr/demo/crypt-des/_des.c /usr/demo/crypt-des/_des.h /usr/demo/crypt-des/test.pl Reference Documents === [1] http://search.cpan.org/~dparis/Crypt-DES-2.05/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
