visual_io.h ioctl definitions [PSARC/2009/224 FastTrack timeout 04/13/2009]
Eric Sultan writes: This case proposes standard ioctls for graphics devices to replace per-device ioctls to fetch device identification information, to fetch EDID data, to fetch PCI config space data, and to store and retrieve the current video mode name. It also proposes an ioctl to perform I/O space access. I'm missing some context here. What per-device ioctls are being replaced? Does this project remove them or are they removed by another project? Does this project also update the Xorg server to use the new ioctls or is there a separate project that depends on these new ioctls? If the latter, then please specify. If neither, then please explain. What privileges are required to invoke the ioctls? Do the I/O register interfaces duplicate what's available through the pcitool (PSARC 2005/232) ioctl interfaces? What's different about these interfaces? What do other platforms do? -- 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
10G link properties [PSARC/2009/206 Self Review]
I requested more time for this case (timing out tomorrow) I'm fine with Paul Garrett's answers. +1 Kais,
sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009]
The timer is set for 8 Apr, 2009. Members as there is no meeting on 8 Apr, I'd like to confirm that all the issues have been resolved. I believe so. I could read Darren's posting to the case as a +1, and I'd like to ensure I've addressed things before moving on. So, I'm asking if there is a formal +1. Gary..
sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009]
Gary Winiger wrote: The timer is set for 8 Apr, 2009. Members as there is no meeting on 8 Apr, I'd like to confirm that all the issues have been resolved. I believe so. I could read Darren's posting to the case as a +1, and I'd like to ensure I've addressed things before moving on. So, I'm asking if there is a formal +1. I'm happy with the responses to my inquiries so I'm formally giving my +1. -- Darren J Moffat
10G link properties [PSARC/2009/206 Self Review]
On 04/07/09 09:40, Kais Belgaied wrote: I requested more time for this case (timing out tomorrow) I'm fine with Paul Garrett's answers. +1 Kais, Thanks! -- Garrett
visual_io.h ioctl definitions [PSARC/2009/224 FastTrack timeout 04/13/2009]
On 04/07/09 04:35, James Carlson wrote: Eric Sultan writes: This case proposes standard ioctls for graphics devices to replace per-device ioctls to fetch device identification information, to fetch EDID data, to fetch PCI config space data, and to store and retrieve the current video mode name. It also proposes an ioctl to perform I/O space access. I'm missing some context here. What per-device ioctls are being replaced? Does this project remove them or are they removed by another project? SPARC graphics projects have traditionally defined Project Private interfaces for some commonly-performed operations such as fetching unparsed EDID data, fetching PCI config space data, and recording video mode names. This proposal does not remove those ioctls, but rather provides standard definitions that could be used across project boundaries for new devices. The previous ioctls wouldn't be removed, though they would become deprecated. Because there is little interest in modifying legacy code, the old ioctls would probably stay in use in the legacy devices. The ioctls to access device I/O space are provided for SPARC processors, which do not implement the inb and outb operations. Those platforms do provide memory-mapped access to I/O space, but that space is not always page-aligned and may not always be mmapable. The I/O access ioctls are limited in scope to the I/O space of the device. Does this project also update the Xorg server to use the new ioctls or is there a separate project that depends on these new ioctls? If the latter, then please specify. If neither, then please explain. The ioctls are not necessarily bound to X. One of the consumers would be the fbconfig utility, which isn't an X client. Fbconfig would use the new ioctl definitions if the target device supports them, and would fallback to prior device-specific ioctls otherwise. But yes, the relevant ddx code in Xorg would be updated to use these interfaces. For example, the AST ddx module would use these. What privileges are required to invoke the ioctls? Read/Write access to the target device is required. The implementation of the ioctls is in the individual device drivers, and so the scope of the potential accesses are the spaces of those devices. This is consistent with the model for all other operations that can read/write device space for SPARC graphics drivers. Do the I/O register interfaces duplicate what's available through the pcitool (PSARC 2005/232) ioctl interfaces? What's different about these interfaces? The ioctls of this proposal to fetch PCI config space and to access device I/O space are specific to the target devices. The interfaces defined by PSARC 2005/232 don't seem to provide a direct way to access a specified device without navigating through the device tree. The interfaces of this proposal are routed directly to the target device needing only the device name. There does seem to be some overlap. The Consolidation Private interfaces of PSARC 2005/232 seem very generalized but require data (bus number, device number, function number, for example) not readily available to the caller. What do other platforms do? The Xorg code has ioctl support for fetching EDID data, but those ioctls are defined in the context of Xorg and not really intended for non-X clients. The EDID ioctls proposed for visual_io.h are not bound to the context of the X server. -- Eric
CIFS Client Commands Update [PSARC/2009/226 Self Review]
I'm sponsoring the following for Gordon Ross. This is an update to an
approved case.
I believe this change qualifies for self-review and I've marked it
Approved Automatic. If anyone disagrees, please let me know and I'll
promote this to a fast-track.
The requested binding is PATCH which matches the binding approved for
the original case.
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:
CIFS Client Commands Update
1.2. Name of Document Author/Supplier:
Author: Gordon Ross
1.3 Date of This Document:
07 April, 2009
4. Technical Description
PSARC 2005/695 CIFS Client on Solaris (approved on 13 Sept 2007)
introduced a new filesystem type: smbfs. Since then the project team
realized that several smbfs-specific commands were not included in the
original case: dfshare_smbfs, share_smbfs, and unshare_smbfs.
The lack of an smbfs-specific dfshares program causes the dfshares(1m)
command to exit with a failure code which causes regression tests to
fail. (See CR 6670499 for details.) The smbfs-specific programs share
and unshare are being included for completeness and conformity with
autofs, cachefs, etc.
This case corrects that oversight and adds the following commands:
/usr/lib/fs/smbfs/dfshares
dfshares_smbfs simply returns an exit code of 0
/usr/lib/fs/smbfs/share
share_smbfs prints smbfs share is not supported
and returns an exit code of 1
/usr/lib/fs/smbfs/unshare
unshare_smbfs prints smbfs unshare is not supported
and returns an exit code of 1
Just as there are no share_{fstype}.1m, unshare_{fstype}.1m, and
dfshares_{fstype}.1m manual pages for autofs and cachefs, there are
also no corresponding manual pages needed for smbfs.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
CIFS Client Commands Update [PSARC/2009/226 Self Review]
I mistyped Gordon's address. This corrects my mistake.
Rich
On 04/07/09 21:03, Rich.Brown at Sun.COM wrote:
I'm sponsoring the following for Gordon Ross. This is an update to an
approved case.
I believe this change qualifies for self-review and I've marked it
Approved Automatic. If anyone disagrees, please let me know and I'll
promote this to a fast-track.
The requested binding is PATCH which matches the binding approved for
the original case.
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:
CIFS Client Commands Update
1.2. Name of Document Author/Supplier:
Author: Gordon Ross
1.3 Date of This Document:
07 April, 2009
4. Technical Description
PSARC 2005/695 CIFS Client on Solaris (approved on 13 Sept 2007)
introduced a new filesystem type: smbfs. Since then the project team
realized that several smbfs-specific commands were not included in the
original case: dfshare_smbfs, share_smbfs, and unshare_smbfs.
The lack of an smbfs-specific dfshares program causes the dfshares(1m)
command to exit with a failure code which causes regression tests to
fail. (See CR 6670499 for details.) The smbfs-specific programs share
and unshare are being included for completeness and conformity with
autofs, cachefs, etc.
This case corrects that oversight and adds the following commands:
/usr/lib/fs/smbfs/dfshares
dfshares_smbfs simply returns an exit code of 0
/usr/lib/fs/smbfs/share
share_smbfs prints smbfs share is not supported
and returns an exit code of 1
/usr/lib/fs/smbfs/unshare
unshare_smbfs prints smbfs unshare is not supported
and returns an exit code of 1
Just as there are no share_{fstype}.1m, unshare_{fstype}.1m, and
dfshares_{fstype}.1m manual pages for autofs and cachefs, there are
also no corresponding manual pages needed for smbfs.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
