[i18n-discuss] EOF of @euro locales [PSARC/2009/342 FastTrack timeout 06/11/2009]
Nicolas Williams Nicolas.Williams at sun.com wrote: It's easiest to resolve by EOFing all non-Unicode locales. But that's not necessarily a practical solution. /usr/bin/vi is listed as non multi byte enabled, you would need to change at least this program, there are others. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
ok. we've descended into design review here, so i'll toss in my $0.02. wrt the comments below, i think that having the X server close and re-open devices during VT switches is a bad idea. too much complexity and lots of opportunites for ugly failures. i understand that the HIDIOCKM?DIRECT ioctls are modeled after the KIOC?DIRECT, but imho, the suggested ioctls also suffer from some ugly potential failure modes as well. for example, what does the X server do if this ioctl call fails. will the VT we switch to work? or if the X server never issues these ioctls (because it's hung or for some other reason), will we switch to a VT that can't get any input? hence, if at all possible, i'd like the kernel to handle all these plumbing changes automatically rather than requiring additional X server interactions whenever a VT switch occurs. so would it be possible to introduce a new ioctl that the X server could use that would tell the kernel that a given device stream (hid, or /dev/mouse, /dev/kbd, etc) is associated with a specific VT? if we had such an ioctl then when the X server opened an input device it would immediatly issue the ioctl to associate the device with the VT it's using. (if the X server isn't using a VT but is instead running on a dedicated framebuffer, it wouldn't issue the ioctl.) that way, the kernel could keep track of input device stream to VT bindings, and when switching between VTs it could automatically redirect device streams as necessary without requiring any interractions from the X server. thoughts? ed On Wed, Jun 03, 2009 at 10:20:38AM +0800, Aaron Zang wrote: I'd like to summarize the request or benefit of this pair of ioctls. 1. Switching from Xorg to console while Xorg is running as a non-root user. Of course we can seteuid() to root, close the input devices and reopen them with root euid again while switching back to Xorg. The thing is the handling of VT switching in xfree86 level of Xorg (not down to Solaris level yet) *disables* the input devices instead of closing them. If we were to adopt the close/reopen way, we need to add Solaris specific code to the xfree86 level which seems ugly to me and does not align with the handling of other OSes. Since the upstream is the Xorg community, the better we make our changes in Solaris specific level the better. Plus, not setting euid to root again reduces the risk of potential security attacks. 2. When we are back on console, Xorg is still listening to HAL. If a keyboard is hooked up, Xorg will get the hotplug inform from HAL and thus will open the keyboard via its hid nodes. This would cause the input routed to the external stream even if we are on the console now. Without the ioctl, the keyboard will not be usable until we switch to Xorg. It could be reproduced on my prototype of Xorg vt support. Maybe the Xorg can ignore the input device hotplugging information while on console, and query the info again upon switching back. But this would involve deciding which input devices are old and which are newly plugged. Complex. 3. hid device driver maintains 2 streams, ioctls to control the routing of input between these 2 streams seems to be a natural thing. If we can save the above complexities with these 2 simple ioctls and accomplish a desirable clear architecture, why not? The above are what I could think of till now. Regards, Aaron On 06/03/09 08:46, Aaron Zang wrote: Actually this case is not with the intention to fix the hotplugged devices bug. Yes, Xorg needs to seteuid(0) back to open the newly plugged devices. But for the existing devices which are already opened, would it be easier and better to just send down a ioctl to switch streams than closing them on switching away and opening them upon switching back with seteuid(0)? I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the shorter of time an application is running with euid 0 the better. Regards, Aaron On 06/03/09 08:28, Alan Coopersmith wrote: James Carlson wrote: Alan Coopersmith writes: That's a bug that was just reported to me in private e-mail while I was out on vacation last week. We need to fix Xorg to setuid back to root before opening hotplugged devices. So ... with that bug fixed, does the need for this special ioctl remain? Doesn't closing the descriptor and reopening it when needed fix the problem? Now that I've had a chance to look at it and not just read the e-mail, I'm trying to determine if that is the correct fix or if the bug is in the kernel side. The devices are owned by the uid Xorg is running as, due to logindevperms, but it seems additional privileges are being required by the kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to require that, then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not been made privilege aware so far since the two
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. sure, but then those redirection ioctls are then private kernel interfaces that the xserver doesn't need to know about them. (there by simplifying the xserver and requiring less solaris specific code within the xserver.) 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT. This would result in conskbd knowing about console/VT details. Still not good. +-+ || | console | || +++ || | || | || +-+---+--+ | | conskbd | | ++---+ | | | | | +-+-+--+ |hid | +--+ why doesn't the VT subsystem keep track of which devices are associated with a given VT? if a hid device get's a vt bind ioctl it could invoke some VT callback function that tracks the binding/association. then when the VT subsystem get's a request to switch VTs, it could redirect io as needed. 3) Say Xorg registers which input device it's using during start up to the kernel, and upon receiving that ioctl, the kernel (either console or conskbd) set up a list of input devices for each VT. What if Xorg gets killed and does not have the chance to issue the ioctl to inform the kernel to free the list? Yes, every opened file would be closed, it could be the hid driver tell the list maintainer to update, would it involve complex interfaces between the 3 components -- console/conskbd/hid? this would need to be managed in two ways. first, if a VT is closed (which is what would presumably happen if the X server died), then all device bindings for that VT are torn down. second, whenever a hid device stream is being closed, it could invoke another VT callback function to let the VT subsystem know that any bindings for that device stream should be torn down. all this io-redirection complexity is being introduced by the fact that we want to support VTs. hence, at least to me, it makes sense to have the VT subsystem track and manage this complexity. handling this all automatically in the VT subsystems seems like a much cleaner approach than forcing every VT consumer (like the X server) to manage system VT device io. ed
rtorrent libtorrent [PSARC/2009/336 FastTrack timeout 06/10/2009]
James Walker wrote: I'm sponsoring this familiarity case for Alex Zhang. The requested release binding is minor. The man pages have been posted in the materials directory. The OpenSSL contract link will be posted after it is approved. I added the approved openssl contract link to the materials directory. Cheers, Jim
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: Hi Ed, I think we are missing some points here. it's quite likely that i'm missing a lot of points, so please be patient with me. The hid (or other devices) are not only associated to VTs. If these devices are exclusively for console uses, it would be great to bind them to VTs. But how about other appliations which access these devices with no regard to console? other apps wouldn't issue the binding ioctl, so they would have exclusive access to the device, regardless of vt switching. just the way it works today. do you have any specific examples of these types of applications and how they work? Say Xorg opens /dev/usb/hid0, and then a privileged application opens /dev/usb/hid0 and starts to read. If switched back to console, input will be switched to the internal stream silently. The user application may starve if never switching back. At least with the HIDIOC[GS]IOCTLS the user application may switch the input back. can you provide an example of this case? it seems to me that if both X and the privileged app try to read from the same stream at the same time, the results will be non-deterministic. (X may get some data and the app may get other bits.) how does this work today? also, do you really expect applications (other than X) to be HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the app with HIDIOCSIOCTLS, how will the app detect that it should be issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did this wouldn't X also start recieving data again as well? The real problem resulting in the Solaris specific code in handling switch in Xorg is because our console/hid... devices are STREAMS based, if they are normal character devices, there won't be any differences. really? i thought the problem was an issue of deciding which consumer of a keyboard/mouse (say console subsystem or an X session) is active, and hence which device consumer should actually be recieving input from the device. is my understanding of the problem correct? if so, how is this decision affected by the device type (streams vs normal character device). ed Regards, Aaron On 06/05/09 14:11, Edward Pilatowicz wrote: On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. sure, but then those redirection ioctls are then private kernel interfaces that the xserver doesn't need to know about them. (there by simplifying the xserver and requiring less solaris specific code within the xserver.) 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT. This would result in conskbd knowing about console/VT details. Still not good. +-+ || | console | || +++ || | || | || +-+---+--+ | | conskbd | | ++---+ | | | | | +-+-+--+ |hid | +--+ why doesn't the VT subsystem keep track of which devices are associated with a given VT? if a hid device get's a vt bind ioctl it could invoke some VT callback function that tracks the binding/association. then when the VT subsystem get's a request to switch VTs, it could redirect io as needed. 3) Say Xorg registers which input device it's using during start up to the kernel, and upon receiving that ioctl, the kernel (either console or conskbd) set up a list of input devices for each VT. What if Xorg gets killed and does not have the chance to issue the ioctl to inform the kernel to free the list? Yes, every opened file would be closed, it could be the hid driver tell the list maintainer to update, would it involve complex interfaces between the 3 components -- console/conskbd/hid? this would need to be managed in two ways. first, if a VT is closed (which is what would presumably happen if the X server died), then all device bindings for that VT are torn down. second, whenever a hid device stream is being closed, it could invoke another VT callback function to let the VT subsystem know that
Introducing non-persistent property group fastreboot_disable_np [PSARC/2009/338 FastTrack timeout 06/10/2009]
Sherry Moore writes: The updated write-up has been copied to the materials directory. +1 -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
PSARC/2009/332 New projects with boundless resources
Updated spec below. Darren This project seeks micro/patch binding. Problem === The /etc/project file has been delivered (PSARC/1999/119) but its delivery did not define how we would add and name new projects, only that the numbers less than 100 were reserved. In addition, it did not offer full support of the features found in the project utilities such as prctl(1). Namespace = Now that the file has been shipped for a number of years, we need to make reasonable guesses about what customers may have done since its delivery. One such guess is that they may have created projects with names similar or the same as SMF FMRIs or executables with which they are associated. Thus in creating a new project to be shipped by default, using a name such as login or init or inetd cannot be considered to be without risk. To provide us with the required flexibility for future enginering, this case proposes that all project names starting with SUNW be reserved and that they are not to be used by customers to define their own projects. This limitation needs to be documented in updates to project(4) and projadd(1M). Removing Limits === Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be 'resource_name=removed'. As an example, it would be possible to use project.max-contracts=removed. Implementation == This cases proposes to implement the above suggestions and to deliver the following changes to the existing platform. New Project ~~~ | This case will deliver a new project called svc.inetd that will be added to /etc/project. The line to be added is: | svc.inetd:5project.max-contracts=remove | The project name svc.inetd is a Project Private interface. svc:/network/inetd:default ~~ The manifest for svc:/network/inetd:default will be updated to define | the default inetd SMF service as a member of the svc.inetd project. Discussion == It is reasonable to ask the question if one daemon has a resource control problem, isn't it likely others will and thus isn't the inetd problem being solved more generic? To answer that question, it behooves us to recognise that inetd is a rather special daemon and in SMF parlance, it is also in a special cateogry - restarter. The problem being investigated here (6271923) is particular to inetd in specific workload testing. Whilst we shouldn't be engineering the system to require tuning, removing limits for all processes removes the protection the limits offer, see PSARC/2004/460. In this regard, the best course of action is for project teams to analyse and understand the execution profiles that their daemons are likely to have and deliver special project defintions as required.
IP Datapath Refactoring [PSARC/2009/331 FastTrack timeout 06/09/2009]
Erik Nordmark writes: The table that I know about is in here: http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/~checkout~/src/usr.bin/netstat/netstat.1?rev=1.51content-type=text/plain ... and it maps RTF_CLONING to 'C' and RTF_CLONED to 'c'. I don't know of a flag that maps to 'W', but I guess it's possible that was done on some system. Ah - I looked at freebsd at http://www.freebsd.org/cgi/man.cgi?query=netstatapropos=0sektion=0manpath=FreeBSD+7.2-RELEASEformat=html which has different flags: C RTF_CLONING Generate new routes on use c RTF_PRCLONINGProtocol-specified generate new routes on use W RTF_WASCLONEDRoute was generated as a result of cloning Interesting ... I guess it's not surprising that there's mutation going on here, though it's puzzling how that RTF_PRCLONING would be used. Lining up with BSD would be a nice thing, if possible, but if we have to be different, I wouldn't complain too much. Which BSD seems to be the key question ;-) I'll stick with 'C'. OK. Note that right now the refactor-gate implementation for local connections doesn't have visibility to the port numbers when it does the ECMP behavior. We'd to fix that to get better spreading. I'm not sure I follow. I thought that the selection mechanism for local connections was described as round-robin. How would port numbers or any ECMP get involved with that? Where is it described as round-robin? In my email where I said currently the kernel only does some form of round robin for default routes? You said this: The project extends the kernel's ability to handle multiple routes for the same prefix; currently the kernel only does some form of round robin for default routes and the project extends that to all off-link routes (default, prefix, and host routes). That text appears to say directly that you're extending the existing round-robin behavior seen for default routes to all off-link routes. Is that not true? The issue is that we don't want the implementation to pick a different route just because some unrelated route change caused a need to revalidate the ire cached for the connection. We do this by having a predictable implementation. My point was that that algorithm can be improved. OK. Hashed IDs instead of round-robin is certainly fine by me. If you go back through the thread, I was just trying to find out exactly what the feature was (and wasn't) supposed to do. Nothing more. At least to me, that's not quite the point. We're _breaking_ that previous feature by permanently disabling it. I think that may well be a good thing -- I can believe that we get acceptably good performance without the complication of MDT -- but I don't think it's useful to say that those things are still supported but simply never work. In which sense is it a feature? It is just a performance trick with a contract private interface. Given that the trick now cost more in support complexity than its benefits, why are we not free to stop using that trick? The IP stack has a contract extended to 'ce' to use it. Would we say we support LSO but then never allow anyone to use it? Do we claim to support MDT? Sure. For example, see: http://docs.sun.com/app/docs/doc/817-0404/appendixa-46?a=view That's still not really the point here. I don't see what that would mean given that the interfaces are contract private, hence no ISV/IHV should use them. I doubt they do. I think you're missing the point I'm making. I think doing this cleanly means obsoleting those old interfaces properly. I do not see any harm in keeping the MDT interfaces in place so that the Cassini driver binaries continue to load into the kernel and work properly. Once Cassini is EOLed we can remove all vestiges of the MDT from the system, but removing it earlier implies addition cost to the business (maintaining another version of the Cassini driver) which doesn't seem warranted. But if you are going to block this case on this issue, then I would be forced to go spend the time to start the EO*L process. I'm not asking about removal of the functions. I agree that'd be quite foolish. It'd break at least the 'ce' driver and do so in violation of the agreed-on contract and for no apparent benefit. But, as I said, I'm not asking for that at all. (Nor do I understand why anyone would think I'd ask for breakage like that or that by asking questions I'd somehow block this case. I never said any such things.) What I am asking for is *merely* documentation. Please explicitly say that this project retires those previous projects (the ARC cases themselves). You could do so by: - Explicitly stating that the interfaces specified in those previous projects are now Obsolete. - Going through the process of notifying the contract holders that the interfaces are going away. That's all.
PSARC/2009/332 New projects with boundless resources
+1 Darren Reed wrote: Updated spec below. Darren This project seeks micro/patch binding. Problem === The /etc/project file has been delivered (PSARC/1999/119) but its delivery did not define how we would add and name new projects, only that the numbers less than 100 were reserved. In addition, it did not offer full support of the features found in the project utilities such as prctl(1). Namespace = Now that the file has been shipped for a number of years, we need to make reasonable guesses about what customers may have done since its delivery. One such guess is that they may have created projects with names similar or the same as SMF FMRIs or executables with which they are associated. Thus in creating a new project to be shipped by default, using a name such as login or init or inetd cannot be considered to be without risk. To provide us with the required flexibility for future enginering, this case proposes that all project names starting with SUNW be reserved and that they are not to be used by customers to define their own projects. This limitation needs to be documented in updates to project(4) and projadd(1M). Removing Limits === Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be 'resource_name=removed'. As an example, it would be possible to use project.max-contracts=removed. Implementation == This cases proposes to implement the above suggestions and to deliver the following changes to the existing platform. New Project ~~~ | This case will deliver a new project called svc.inetd that will be added to /etc/project. The line to be added is: | svc.inetd:5project.max-contracts=remove | The project name svc.inetd is a Project Private interface. svc:/network/inetd:default ~~ The manifest for svc:/network/inetd:default will be updated to define | the default inetd SMF service as a member of the svc.inetd project. Discussion == It is reasonable to ask the question if one daemon has a resource control problem, isn't it likely others will and thus isn't the inetd problem being solved more generic? To answer that question, it behooves us to recognise that inetd is a rather special daemon and in SMF parlance, it is also in a special cateogry - restarter. The problem being investigated here (6271923) is particular to inetd in specific workload testing. Whilst we shouldn't be engineering the system to require tuning, removing limits for all processes removes the protection the limits offer, see PSARC/2004/460. In this regard, the best course of action is for project teams to analyse and understand the execution profiles that their daemons are likely to have and deliver special project defintions as required.
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 06/04/2009]
This case has timed out with a +1 and no issues and has been marked closed approved. - John
rtorrent libtorrent [PSARC/2009/336 FastTrack timeout 06/10/2009]
Hi all Thanks for the reply. A good news, it seem that this isn't a problem now. I just download the other libtorrent -- libtorrent- rasterbar-0.14.4.tar.gz, after compile it, I saw it generate a library named libtorrent- rasterbar.so In its compile options, I saw this define: -DPACKAGE_NAME=\libtorrent- rasterbar\ also the include directory it exported is named libtorrent, while our libtorrent's include directory named torrent. That means there is not any conflict between both libtorrent now. When we try to port libtorrent-rasterbar later, we can give it an other package name : SUNWlibtorrent-rasterbar. Thanks - Alex On Jun 4, 2009, at 8:36 PM, James Carlson wrote: Andras Barna writes: yeap they have libtorrent-rasterbar.so for libtorrent-rastebar and for rakshasa's simply libtorrent. so we can go this way too (if noone has other idea(s)) If the library isn't really well-accepted in the open source community (i.e., it has just one consumer *and* there's an alternative that has many consumers), then making it a static library makes a lot more sense to me. That way, you don't have to deal with either the package naming or the /usr/lib real estate issues. You can always break it back apart later and deliver it as a dynamic library if you find that someone else needs it. -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[Fwd: Re: bvi [PSARC/2009/326 FastTrack timeout 06/04/2009]]
Jim Walker wrote: Vector, Can you comment on this? Cheers, Jim Hi Jim, Thanks for your help. Subject: Re: bvi [PSARC/2009/326 FastTrack timeout 06/04/2009] From: Alan Coopersmith Alan.Coopersmith at Sun.COM Date: Thu, 28 May 2009 15:34:28 -0700 To: James Walker jw137282 at sac.sfbay.sun.com To: James Walker jw137282 at sac.sfbay.sun.com CC: PSARC-ext at Sun.COM, Vector.Li at Sun.COM James Walker wrote: 4.2 Imported Interfaces Interface Name Classification Comments --- -- None Does this mean it will be using the standard curses library and not ncurses? (ncurses would need to be called out in the imported interfaces since it's Volatile, and a Contract required. The configure script allows using either one depending on flags.) Yes, it uses standard curses library. By default, to build bvi, we run configure as: $ ./configure --prefix=/usr --mandir=/usr/share/man --libdir=/usr/share/bvi and we don't support this option (I don't think it is necessary to support as it is optional), --with-ncurses=DIRpath to ncurses So package SUNWbvi does not have a dependency on ncurses. -- Regards, Vector Tel: +86-10-6267-3534 | SWAN: x80534
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT. This would result in conskbd knowing about console/VT details. Still not good. +-+ || | console | || +++ || | || | || +-+---+--+ | | conskbd | | ++---+ | | | | | +-+-+--+ |hid | +--+ 3) Say Xorg registers which input device it's using during start up to the kernel, and upon receiving that ioctl, the kernel (either console or conskbd) set up a list of input devices for each VT. What if Xorg gets killed and does not have the chance to issue the ioctl to inform the kernel to free the list? Yes, every opened file would be closed, it could be the hid driver tell the list maintainer to update, would it involve complex interfaces between the 3 components -- console/conskbd/hid? Regards, Aaron On 06/05/09 10:20, Edward Pilatowicz wrote: ok. we've descended into design review here, so i'll toss in my $0.02. wrt the comments below, i think that having the X server close and re-open devices during VT switches is a bad idea. too much complexity and lots of opportunites for ugly failures. i understand that the HIDIOCKM?DIRECT ioctls are modeled after the KIOC?DIRECT, but imho, the suggested ioctls also suffer from some ugly potential failure modes as well. for example, what does the X server do if this ioctl call fails. will the VT we switch to work? or if the X server never issues these ioctls (because it's hung or for some other reason), will we switch to a VT that can't get any input? hence, if at all possible, i'd like the kernel to handle all these plumbing changes automatically rather than requiring additional X server interactions whenever a VT switch occurs. so would it be possible to introduce a new ioctl that the X server could use that would tell the kernel that a given device stream (hid, or /dev/mouse, /dev/kbd, etc) is associated with a specific VT? if we had such an ioctl then when the X server opened an input device it would immediatly issue the ioctl to associate the device with the VT it's using. (if the X server isn't using a VT but is instead running on a dedicated framebuffer, it wouldn't issue the ioctl.) that way, the kernel could keep track of input device stream to VT bindings, and when switching between VTs it could automatically redirect device streams as necessary without requiring any interractions from the X server. thoughts? ed On Wed, Jun 03, 2009 at 10:20:38AM +0800, Aaron Zang wrote: I'd like to summarize the request or benefit of this pair of ioctls. 1. Switching from Xorg to console while Xorg is running as a non-root user. Of course we can seteuid() to root, close the input devices and reopen them with root euid again while switching back to Xorg. The thing is the handling of VT switching in xfree86 level of Xorg (not down to Solaris level yet) *disables* the input devices instead of closing them. If we were to adopt the close/reopen way, we need to add Solaris specific code to the xfree86 level which seems ugly to me and does not align with the handling of other OSes. Since the upstream is the Xorg community, the better we make our changes in Solaris specific level the better. Plus, not setting euid to root again reduces the risk of potential security attacks. 2. When we are back on console, Xorg is still listening to HAL. If a keyboard is hooked up, Xorg will get the hotplug inform from HAL and thus will open the keyboard via its hid nodes. This would cause the input routed to the external stream even if we are on the console now. Without the ioctl, the keyboard will not be usable until we switch to Xorg. It could be reproduced on my prototype of Xorg vt support. Maybe the Xorg can ignore the input device hotplugging information while on console, and query the info again upon switching back. But this would involve deciding which input
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
Hi Ed, I think we are missing some points here. The hid (or other devices) are not only associated to VTs. If these devices are exclusively for console uses, it would be great to bind them to VTs. But how about other appliations which access these devices with no regard to console? Say Xorg opens /dev/usb/hid0, and then a privileged application opens /dev/usb/hid0 and starts to read. If switched back to console, input will be switched to the internal stream silently. The user application may starve if never switching back. At least with the HIDIOC[GS]IOCTLS the user application may switch the input back. The real problem resulting in the Solaris specific code in handling switch in Xorg is because our console/hid... devices are STREAMS based, if they are normal character devices, there won't be any differences. Regards, Aaron On 06/05/09 14:11, Edward Pilatowicz wrote: On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. sure, but then those redirection ioctls are then private kernel interfaces that the xserver doesn't need to know about them. (there by simplifying the xserver and requiring less solaris specific code within the xserver.) 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT. This would result in conskbd knowing about console/VT details. Still not good. +-+ || | console | || +++ || | || | || +-+---+--+ | | conskbd | | ++---+ | | | | | +-+-+--+ |hid | +--+ why doesn't the VT subsystem keep track of which devices are associated with a given VT? if a hid device get's a vt bind ioctl it could invoke some VT callback function that tracks the binding/association. then when the VT subsystem get's a request to switch VTs, it could redirect io as needed. 3) Say Xorg registers which input device it's using during start up to the kernel, and upon receiving that ioctl, the kernel (either console or conskbd) set up a list of input devices for each VT. What if Xorg gets killed and does not have the chance to issue the ioctl to inform the kernel to free the list? Yes, every opened file would be closed, it could be the hid driver tell the list maintainer to update, would it involve complex interfaces between the 3 components -- console/conskbd/hid? this would need to be managed in two ways. first, if a VT is closed (which is what would presumably happen if the X server died), then all device bindings for that VT are torn down. second, whenever a hid device stream is being closed, it could invoke another VT callback function to let the VT subsystem know that any bindings for that device stream should be torn down. all this io-redirection complexity is being introduced by the fact that we want to support VTs. hence, at least to me, it makes sense to have the VT subsystem track and manage this complexity. handling this all automatically in the VT subsystems seems like a much cleaner approach than forcing every VT consumer (like the X server) to manage system VT device io. ed -- You know some birds are not meant to be caged, their feathers are just too bright.
HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]
On 06/05/09 15:52, Edward Pilatowicz wrote: On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: Hi Ed, I think we are missing some points here. it's quite likely that i'm missing a lot of points, so please be patient with me. The hid (or other devices) are not only associated to VTs. If these devices are exclusively for console uses, it would be great to bind them to VTs. But how about other appliations which access these devices with no regard to console? other apps wouldn't issue the binding ioctl, so they would have exclusive access to the device, regardless of vt switching. just the way it works today. Other applications may share the same devices with Xorg which are bind to certain VT by Xorg. do you have any specific examples of these types of applications and how they work? No. But occasionally I need to cat /dev/usb/hid0 to see if my keyboard is still working. If a user does that on purpose, he probably won't want to lose input, especially for a long time. That might not be a very proper example. Just the idea of Xorg binding shared devices to VTs seems very weird to me. Say Xorg opens /dev/usb/hid0, and then a privileged application opens /dev/usb/hid0 and starts to read. If switched back to console, input will be switched to the internal stream silently. The user application may starve if never switching back. At least with the HIDIOC[GS]IOCTLS the user application may switch the input back. can you provide an example of this case? it seems to me that if both X and the privileged app try to read from the same stream at the same time, the results will be non-deterministic. (X may get some data and the app may get other bits.) how does this work today? Yes, if they are both reading the results will be non-deterministic. When switched away, Xorg may not be reading input, though it still keeps the file open, but the other application may still reading. Even when Xorg is active, it polls the input devices, so if there are other applications reading the same input device, the input would likely be read by the application. I tried /dev/usb/hid0 in my gnome terminal, it seems this thread gets all the input since the characters echoed on the terminal is not recognizable. also, do you really expect applications (other than X) to be HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the app with HIDIOCSIOCTLS, how will the app detect that it should be issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did this wouldn't X also start recieving data again as well? My thoughts are if we switch streams automatically during switch if would be UNFAIR for other applications not be able to switch them back. There might not be any existing well known applications do that, but we can not rule out the possibility, especially in the future. The application could set up a timer, if it expires, it could check the direction and if switched away, switched back, it is privileged application, it could do anything it likes. The real problem resulting in the Solaris specific code in handling switch in Xorg is because our console/hid... devices are STREAMS based, if they are normal character devices, there won't be any differences. really? i thought the problem was an issue of deciding which consumer of a keyboard/mouse (say console subsystem or an X session) is active, and hence which device consumer should actually be recieving input from the device. is my understanding of the problem correct? if so, how is this decision affected by the device type (streams vs normal character device). If not STREAMS based, you do not need to switch streams. Just stop reading the input devices if switched away. Regards, Aaron ed Regards, Aaron On 06/05/09 14:11, Edward Pilatowicz wrote: On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. sure, but then those redirection ioctls are then private kernel interfaces that the xserver doesn't need to know about them. (there by simplifying the xserver and requiring less solaris specific code within the xserver.) 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT.
Coherence [LSARC/2009/199 FastTrack timeout 04/08/2009]
A minor change to the coherence onepager. The following package was added to the Exported Interface table to contain the SMF integration files. SUNWpython24-coherence-rootUncommitted Package name to contain SMF integration files. And also section 4.10 was updated to list the new package name as well: 4.10. Packaging Delivery: Adds new packages: SUNWpython24-coherence, SUNWpython24-coherence-root, and SUNWpython26-coherence Brian Brian Cameron wrote: 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: Coherence 1.2. Name of Document Author/Supplier: Author: Alfred Peng 1.3 Date of This Document: 25 March, 2009 4. Technical Description Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Coherence 1.2. Name of Document Author/Supplier: Alfred Peng 1.3. Date of This Document: 03/13/2009 1.3.1. Date this project was conceived: 07/12/2007 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is Sponsoring this project: robert.odea at sun.com 1.4.4. The name of your business unit: New Solaris Group, Desktop 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy at sun.com 1.5.2. Responsible Engineer: alfred.peng at sun.com 1.5.3. Marketing Manager: glynn.foster at sun.com 1.5.4. Interest List: desktop-discuss at opensolaris.org 4. Technical Description: 4.1. Details: Coherence is a DLNA (Digital Living Network Alliance)/UPnP (Universal Plug and Play) Framework written in Python for the Digital Living. The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and in corporate environments for simplified installation of computer components. With the UPnP framework, users can setup their home media center with PCs, wireless devices (mobile phones, tablet PCs etc.) and networked appliances (TVs, audio players, multimedia players, games consoles etc.)[2]. Coherence is divided into three main parts: the core, the virtual devices, and the device backends[3]. The core of coherence provides an implementation of: a SSDP (Simple Service Discovery Protocol) [4] server, a MSEARCH (command to find other devices connected to the UPnP network) client to find other devices connected to the network, server and client for HTTP/SOAP requests, server and client for Event Subscription and Notification. The virtual devices contain: Media Server to provide media content (local storage or online services) and directory information, Media Renderer to play back media content provided by the Media Server, Control Point to interconnect Media Server and Media Renderer. The virtual device implementation registers with the core, declares which service interfaces it is using, and attaches callbacks which map the service actions to its backend. It's generally a translation map between the core and the device backend. The device backend is the part to host, render and control the media files. The following components could act as the device backend: file systems to store the media files, audio/video hardware and desktop GUI applications to render the media content and control the playback. For users, coherence can be used in conjunction with Rhythmbox, Totem or Elisa, and become a controllable DLNA/UPnP Media Renderer. For example, coherence is used in Elisa to talk with the Apple Movie trailer Media Server for its Movie trailer plugin and YouTube Media Server for its YouTube plugin. Coherence can also be configured as a DLNA/UPnP Media Server and exports local and remote media files via its backend to other UPnP clients. Developers get a python framework with an emerging DBus API. This framework is designed to automate all UPnP-related tasks as much as possible and enable applications to participate in digital living networks. In short, coherence provides two main features
Obsoleting the multi-data transmit contracted interfaces [Re: IP Datapath Refactoring [PSARC/2009/331 FastTrack timeout 06/09/2009]
Yatin, [I assume you are the best contact to notify about this.] The IP datapath refactoring project will make TCP/IP stop sending down M_MULTIDATA messages to the device drivers. However, the different ARCed interfaces remain in the system thus the Cassini driver will *not* need any changes. To accurately reflect this I've asked the interfaces in PSARC 2004/594 and PSARC 2002/276 to be marked as Obsolete. (In some future when the Cassini driver has been EOLed we can consider removing those interfaces from the system.) The two contracts have the following contacts at your end. http://sac.eng/arc/PSARC/2004/594/contract-01.txt 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: NSPG Department or Group: NCS Connectivity Bugtraq Category/SubCategory: ethernet_cassini/cassini_sw Responsible Manager: Leo Hejza http://sac.eng/arc/PSARC/2002/276/contract-001 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: OS/Networking Department or Group:NS/Cassini Bugtraq Category/SubCategory: ethernet_cassini/cassini_sw Responsible Manager:Jay Jayachandran Erik
IP Datapath Refactoring [PSARC/2009/331 FastTrack timeout 06/09/2009]
Here is the updated writeup, with draft man page diffs. Hopefully this clarifies things. Erik -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ipd.psarc2 URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090605/dd75477c/attachment.ksh -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ipd.psarc.netstat.diff URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090605/dd75477c/attachment-0001.ksh -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ipd.psarc.route.diff URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090605/dd75477c/attachment-0002.ksh -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ipd.psarc.route7p.diff URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090605/dd75477c/attachment-0003.ksh
VSD locking update [PSARC/2009/343 FastTrack timeout 06/12/2009]
I'm sponsoring the following fast-track for Bob Mastors. This case is an update to PSARC 2007/456 Vnode Specific Data and adds a new field to the vnode structure (in sys/vnode.h): v_vsd_lock. The case seeks Minor binding which matches the binding of the original case. The timer expires on June 12, 2009. 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: VSD locking update 1.2. Name of Document Author/Supplier: Author: Bob Mastors 1.3 Date of This Document: 05 June, 2009 4. Technical Description PSARC 2007/456 Vnode Specific Data was created to easily associate project specific data with a vnode. The current implementation requires consumers of vsd_get() and vsd_set() to hold the vnode v_lock mutex across the calls. However, vsd_set() may go to sleep on kmem_alloc(). This could cause the system to deadlock if the vnode had dirty pages that needed to be written. This problem is described by: 6839233 VSD usage of v_lock could cause deadlock The solution adds a new mutex to vnode_t: kmutex_tv_vsd_lock;/* protects v_vsd field */ Consumers of vsd_get() and vsd_set() would hold v_vsd_lock across the calls instead of v_lock. There are no lock ordering issues since the locks are independent and there is no reason to hold both simultaneously. Currently, the only ON consumer of vsd_get() and vsd_set() is NFS. Exported Interfaces Interface Name | Classification | Comments = || v_vsd_lock | Consolidation | New mutex in the vnode structure | Private| to protect v_vsd field 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
PSARC/2009/332 New projects with boundless resources
Removing Limits === Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be 'resource_name=removed'. As an example, it would be possible to use project.max-contracts=removed. I assume we would maintain the current removal behavor, which is done by specifying the rctl name without any value? -Steve L.
PSARC/2009/332 New projects with boundless resources
Darren Reed wrote: Updated spec below. Darren This project seeks micro/patch binding. Problem === The /etc/project file has been delivered (PSARC/1999/119) but its delivery did not define how we would add and name new projects, only that the numbers less than 100 were reserved. In addition, it did not offer full support of the features found in the project utilities such as prctl(1). Namespace = Now that the file has been shipped for a number of years, we need to make reasonable guesses about what customers may have done since its delivery. One such guess is that they may have created projects with names similar or the same as SMF FMRIs or executables with which they are associated. Thus in creating a new project to be shipped by default, using a name such as login or init or inetd cannot be considered to be without risk. To provide us with the required flexibility for future enginering, this case proposes that all project names starting with SUNW be reserved and that they are not to be used by customers to define their own projects. This limitation needs to be documented in updates to project(4) and projadd(1M). Don't you want to update this paragraph to reserve the svc.name namespace instead? Scott Removing Limits === Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be 'resource_name=removed'. As an example, it would be possible to use project.max-contracts=removed. Implementation == This cases proposes to implement the above suggestions and to deliver the following changes to the existing platform. New Project ~~~ | This case will deliver a new project called svc.inetd that will be added to /etc/project. The line to be added is: | svc.inetd:5project.max-contracts=remove | The project name svc.inetd is a Project Private interface. svc:/network/inetd:default ~~ The manifest for svc:/network/inetd:default will be updated to define | the default inetd SMF service as a member of the svc.inetd project. Discussion == It is reasonable to ask the question if one daemon has a resource control problem, isn't it likely others will and thus isn't the inetd problem being solved more generic? To answer that question, it behooves us to recognise that inetd is a rather special daemon and in SMF parlance, it is also in a special cateogry - restarter. The problem being investigated here (6271923) is particular to inetd in specific workload testing. Whilst we shouldn't be engineering the system to require tuning, removing limits for all processes removes the protection the limits offer, see PSARC/2004/460. In this regard, the best course of action is for project teams to analyse and understand the execution profiles that their daemons are likely to have and deliver special project defintions as required. -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
