krb5_ldap_util command for Solaris Kerberos [PSARC/2007/368 FastTrack timeout 06/26/,2007]
Wyllys Ingersoll wrote: I am sponsoring the following fast-track for Will Fiveash. * The release binding is patch/micro. * The interface stability is committed. * The timer is set for 1 week (6/27/2007) - Wyllys Ingersoll Should something marked This information is Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know and containing names of customers really have been sent to psarc-ext? Couldn't you have redacted the customer names before sending it out? James C. McPherson -- Solaris kernel software engineer Sun Microsystems
Include GNU nano 2.0.6 [PSARC/2007/366 FastTrack timeout06/25/2007]
Gary Winiger wrote: (Getting used to new sac_nextcase...) I'm sponsoring the nano case for myself. It seeks Patch binding. The spec never made it to the mail file. I'm including it here. Gary.. PSARC/2007/366 Include GNU nano 2.0.6 Stephen Hahn (sch at sun.com) ident $Hg: d-gnu-nano-fast-track.txt bdb36266acd3 2007/06/18 11:22:10 -0700 $ SMI 1. Summary This case adds the GNU/FSF visual editor, nano(1), under the integration guidelines for /usr/gnu [1]. Patch binding is sought for this case. 2. Discussion The GNU visual editor, nano(1), offers a simple editor suitable for new users to a Unix terminal environment. (For instance, nano displays the available command menu on the bottom two lines of the terminal.) Both the regular and restricted forms of the editor will be included; like restricted shells, rnano(1) allows a limited set of operations: access only to files provided as arguments, no job suspension, and so forth. Based on community discussion, the initial integration will provide the default feature set, plus support for colour, multiple edit buffers, and per-user configuration. Slightly offtopic: Does nano support multibyte characters (e.g. en_US.UTF-8, ja_JP.PCK or zh_CN.GB18030) ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
2007/355 ddi_modopen Stability Promotion
but in your example below, are you delivering firmware in these misc modules? or are these misc modules essentially modular plugins for the scsi_vhci driver? (i thought they were the latter.) this arc case was proposing that the promotion of ddi_modopen() and friends was for the specific purpose of loading hardware firmware modules, but there would be no reason that driver writers wouldn't be able to use these interfaces for modularization purposes as well, in which case it seems that the documentation for these interfaces should provide some module naming advice for both scenarios. ed On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: The reason I did not push naming in the original case was because it is easy to get wrong, esp if you don't have much use experience. We have some more experience now. For driver use, my recommendation is to fix 6504975 ddi_modopen should allow open in subdirectory and tell people to deliver into a directory in misc that has the same name as the driver. This is what we plan to do as part of opensource for mpxio/scsi_vhci. -Chris # modinfo | grep scsi_vhci 22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) 24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) 25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) 26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) 27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) 28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) 29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) # ls -R /kernel/misc/scsi_vhci /kernel/misc/scsi_vhci: sparcv9 /kernel/misc/scsi_vhci/sparcv9: scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs # find /kernel/drv -name scsi_vhci -print /kernel/drv/sparcv9/scsi_vhci Tzongyu Paul Lee writes: I would suggest that you take some leadership to avoid potential name space pollution that is hard to undo later. The suggestion of using driver name as prefix with special _extension is quite reasonable. I like the idea. We are counting on the disambiguating power of driver name, and that's a good start. You can recommend the use of of version/date/descriptive word to driver writers to manage their own name space as they see fit. I would not suggest baking version numbers or (worse) dates into path names unless there's a _really_ good reason to do so. Merely disambiguating modules is not a good reason. (On the other hand, if we had a magical kernel that could deal with multiple versions of the same module on the system at the same time, then that'd be a good reason.) The original 2005/050 case had a proposal for the naming scheme and, though I asked the submitter of this case about it, I'm really not clear on why this wasn't just brought forward: [stock-symbol_]purpose_variation[.version] For legacy Sun-developed plug-in 'misc' modules the stock-symbol is optional, new Sun-developed modules and third party modules should specify their stock-symbol (SUNW, etc) to avoid name conflicts. If there is only one consumer then purpose may be the consuming modulename (svm's meta disk driver (md(7D) would use md), otherwise a more generic name should be used to express purpose. The variation field describes what variation of an interface is implemented by the plug-in (the legacy md_mirror module implements mirroring below the md driver). The version field is optional, it might be used if programmer decides to implement by-mod-name versioning. (Personally, I'd lose the version goop here, as it only adds to the potential for disaster, but if it's only a recommendation, I'm slightly less concerned.)
2007/355 ddi_modopen Stability Promotion
Hi Ed but in your example below, are you delivering firmware in these misc modules? or are these misc modules essentially modular plugins for the scsi_vhci driver? (i thought they were the latter.) In the example I gave they are plugins, but putting modules that driver xxx is going to ddi_modopen(9F) in a misc/xxx directory helps scope the namespace in both cases (i.e. I think the advise applies to both situations). It also makes sense for these modules to be below misc because they use misc modlinkage(9s). In addition to the man pages in the original case http://sac.eng/PSARC/2005/050/, this case should also introduce a new modlmisc(9s) peer of modldrv(9s) and modlstrmod(9s) (I missed that in the original case). What's missing is an registry of driver names. We have some registry links available in the bottom of the left hand column of http://sac.eng/arc, but there is nothing for driver names (or kernel-module names). (NOTE: this could be initially populated by extracting information from collected customer explorer data). -Chris this arc case was proposing that the promotion of ddi_modopen() and friends was for the specific purpose of loading hardware firmware modules, but there would be no reason that driver writers wouldn't be able to use these interfaces for modularization purposes as well, in which case it seems that the documentation for these interfaces should provide some module naming advice for both scenarios. ed On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: The reason I did not push naming in the original case was because it is easy to get wrong, esp if you don't have much use experience. We have some more experience now. For driver use, my recommendation is to fix 6504975 ddi_modopen should allow open in subdirectory and tell people to deliver into a directory in misc that has the same name as the driver. This is what we plan to do as part of opensource for mpxio/scsi_vhci. -Chris # modinfo | grep scsi_vhci 22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) 24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) 25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) 26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) 27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) 28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) 29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) # ls -R /kernel/misc/scsi_vhci /kernel/misc/scsi_vhci: sparcv9 /kernel/misc/scsi_vhci/sparcv9: scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs # find /kernel/drv -name scsi_vhci -print /kernel/drv/sparcv9/scsi_vhci Tzongyu Paul Lee writes: I would suggest that you take some leadership to avoid potential name space pollution that is hard to undo later. The suggestion of using driver name as prefix with special _extension is quite reasonable. I like the idea. We are counting on the disambiguating power of driver name, and that's a good start. You can recommend the use of of version/date/descriptive word to driver writers to manage their own name space as they see fit. I would not suggest baking version numbers or (worse) dates into path names unless there's a _really_ good reason to do so. Merely disambiguating modules is not a good reason. (On the other hand, if we had a magical kernel that could deal with multiple versions of the same module on the system at the same time, then that'd be a good reason.) The original 2005/050 case had a proposal for the naming scheme and, though I asked the submitter of this case about it, I'm really not clear on why this wasn't just brought forward: [stock-symbol_]purpose_variation[.version] For legacy Sun-developed plug-in 'misc' modules the stock-symbol is optional, new Sun-developed modules and third party modules should specify their stock-symbol (SUNW, etc) to avoid name conflicts. If there is only one consumer then purpose may be the consuming modulename (svm's meta disk driver (md(7D) would use md), otherwise a more generic name should be used to express purpose. The variation field describes what variation of an interface is implemented by the plug-in (the legacy md_mirror module implements mirroring below the md driver). The version field is optional, it might be used if programmer decides to implement by-mod-name versioning. (Personally, I'd lose the version goop here, as it only adds to the potential for disaster, but if it's only a recommendation, I'm slightly less concerned.)
krb5_ldap_util command for Solaris Kerberos [PSARC/2007/368 FastTrack timeout 06/26/,2007]
On Tue, Jun 19, 2007 at 09:49:48PM -0400, Wyllys Ingersoll wrote: James C. McPherson wrote: Wyllys Ingersoll wrote: I am sponsoring the following fast-track for Will Fiveash. * The release binding is patch/micro. * The interface stability is committed. * The timer is set for 1 week (6/27/2007) - Wyllys Ingersoll Should something marked This information is Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know and containing names of customers really have been sent to psarc-ext? I think the form used was just an old template and the submitter forgot to edit that stuff out. Likewise, I should have caught it but didn't notice it either. It is not actually need-to-know or we wouldn't have sent it to psarc-ext. Take a look at: http://sac.eng.sun.com/sdf/SDF-Templates/onepager.txt I see: Template Version: %Z%%M% %I% %E% SMI This information is Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know Copyright 2006 Sun Microsystems Seems like a couple things need to be fixed in the official template. -- Will Fiveash
krb5_ldap_util command for Solaris Kerberos [PSARC/2007/368 FastTrack timeout 06/26/,2007]
Will Fiveash wrote: Take a look at: http://sac.eng.sun.com/sdf/SDF-Templates/onepager.txt Actually, please don't. The One Pager is almost always the wrong form to fill out for an ARC fast-track - all the stuff about marketing and business requirements is not useful for ARC review and just gets in the way of both ARC review and publishing to OpenSolaris. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
2007/369 auths(1) Update
Ah, zsh. :)
[[ ${#${(M)${(s:,:)$(auths)}:#solaris.date}} -eq 1 ]]
+ if [ ! auths -a solaris.date ]
But regardless of shell choice, that's wrong. Ditch the brackets:
if ! auths -a solaris.date
...
The project team sent me an update to rbac.5 that includes
Danek's kind code review comment. The materials are so
updated.
Gary..
2007/355 ddi_modopen Stability Promotion
On Wed, 2007-06-20 at 00:53 -0700, Edward Pilatowicz wrote: but in your example below, are you delivering firmware in these misc modules? or are these misc modules essentially modular plugins for the scsi_vhci driver? (i thought they were the latter.) this arc case was proposing that the promotion of ddi_modopen() and friends was for the specific purpose of loading hardware firmware modules, but there would be no reason that driver writers wouldn't be able to use these interfaces for modularization purposes as well, in which case it seems that the documentation for these interfaces should provide some module naming advice for both scenarios. indeed. i'd be happer if these two aspects of the case were disentangled. ddi_modopen() has general utility broader than its use to get at firmware images encapsulated in a kernel module, and would promote its stability as-is.
2007/369 auths(1) Update
This case was approved at today's PSARC meeting. Gary..
