PSARC 2008/754 RealTek RTL8187L USB 802.11b/g Wireless Driver
Cecilia Hu ??: Sebastien Roy wrote: On Fri, 2008-12-05 at 12:51 +0800, Cecilia Hu wrote: The architecture and interface of it are clear enough to be a self review, so the case is marked as closed approved automatic. I think that now that drivers affect system-wide administratively visible behavior unrelated to their immediate function such as the system's ability to do suspend/resume and fast-reboot, I think some more details are needed beyond what was originally provided. Does the driver have proper support for DDI_SUSPEND in its detach() routine, and for DDI_RESUME in its attach() routine? Given that it's USB, does it even need to for the system to suspend/resume with such a device? Similar question for quiesce() and fast-reboot. All device driver cases should probably include such details to preempt these kinds of questions. Good points and I agree. Those parts should be included in further driver cases. About this one, urtw, AFAIK: . suspend/resume: supports . quiesce and fast-reboot: supports btw: urtw driver will support fast-reboot by register ddi_quiesce_not_needed. . brussels: supports Thanks, Michael
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 11:28:16AM +1100, Darren Reed wrote: John, What's the plan for mailx(1) use of of mailwrapper? Is it intended for mailx(1) to remain as a frontend to sendmail (only) or will it also use mailwrapper(1M)? If it's going to use mailwrapper(1M), then this case looks a bit incomplete as mailx(1) seems to suggest a few bits of its functionality are tied to sendmail... General usage is covered by an entry for mail in mailer.conf. The conv functionality, while alluding to a (undocumented) -U option to sendmail(1M), is implemented internally to mailx(1). I can see -h, -m/metoo and possibly -v/verbose being an issue if a user decides to switch out sendmail; would warnings in the manuals cover this? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/db98a3fd/attachment.bin
ddi_ssoft_state(9F) and ddi_isoft_state(9F) [PSARC/2008/755 FastTrack timeout 12/17/2008]
Chris Horne wrote: Hi Garrett Garrett D'Amore wrote: Chris Horne wrote: Hi Ed hey chris, the current ddi soft state interfaces are special in my mind because i thought they were designed to be fast. (note that i wasn't around for the original design, so my opinion is based off the implmentation.) their implementation uses direct array indexing, avoids locking, and avoids free memory, all seemingly in the name of soft state lookup speed. i guess i'm worried that other people may be making the same assumptions about the performance of the ddi soft state interfaces, and these assumptions don't really carry over to the new interfaces since they are really a thin wrapper around modhash. Yes, performance is an issue for interfaces used in the per-IO code path. For the intended use case, the proposed ddi_ssoft_state will not be 'directly' involved in the performance path. In the intended use case, the performance path 'indirectly' gains access to the target-port granularity ddi_ssoft_state via a private pointer maintained in the finer-grained target-port,lun per-scsi_device(9S) hba private soft state (PSARC/2008/675). At tran_tgt_init(9E) time of a scsi_device(9S), the hba driver is expected to ddi_ssoft_state_get(9F) the coarser target-port softstate, and increment a private target-port softstate reference count to account for storing a target-port softstate pointer in the finer-grained per-scsi_device(9S) hba private softstate. hence, i'd rather see something more straitforward, like some version/subset of the modhash interfaces promoted to public, or some new ddi*hash* interfaces. I want the ability to say its a softstate, but you feed it strings instead of integers. With that simple statement, I believe that anyone who has written a solaris driver would get it. I don't want to loose that. But in your intended usage, it *isn't* a soft state, at least not like I suspect most people thing of such things (one per device instance, the master private state for the devinfo node.) ...and I am proposing a peer that is string based. If we had a separate devinfo node to represent the target port addressing, we would have an instance-oriented softstate there - but that is not how the IEEE1275 binding for scsi devices works. Who says that all forms of soft state need to be indexed by integers (or that those integers need to be instance numbers)? I view soft state as a generic term for (private) software state. Of course you can use ddi_soft_state_xxx for other purposes, but its pretty clear from the examples, naming, and existing practice that this is what it is intended for. Some of the specific details of memory allocation and life time of objects really make sense only in the context of soft state that is managed like instance data. I actually fear that this naming will increase confusion (which soft state interfaces should I use?) Keep in mind that any part of the device tree that has multiple complex addressing levels compressed into a single devinfo node unit-address (@component-a,component-b,component-c) will face this problem - which is why I thought the ddi_ssoft_* prefix was warranted. The solution to performance path issues will likely involve a private ref_count approach similar to our use case above. If the above explanation is insufficient, to make progress, I am willing to change the interface prefix from ddi_ssoft_state_* to scsi_taddr_ssoft_state_*, indicating a more restricted use case that meets immediate needs. FWIW, I'd be happy with that. I'd be equally happy with a generic hash table interface. not this case. Why not? What you're proposing (or rather what you need) is a generic dictionary lookup mechanism mapping strings to some state. The only additional bits are that this case also imposes some additional memory management features (i.e. state structures are fixed sized, and allocation is managed by the API rather than by the calling driver.) Though I'd suggest you just call it scsi_taddr_state_*() or somesuch. (Avoid the non-descriptive s prefix, and keep the identifier short.) Even in my immediate use case the scsi_taddr prefix is misleading because we will be using it for scsi, smp, and sata device target port addresses seen on a sas transport - but I will make the prefix change if people insist. How about ddi_named_state_xxx? That will avoid the problem of confusion with ddi_soft_state, and make it a bit clearer (IMO). I'd recommend that you also consider a set of APIs to *walk* the data structure, because in my own experience the inability to easily walk the ddi_soft_state_xxx list is one of the limiting factors in its use. (On more than one occasion I've had to either make my own global linked list in addition to, or instead of, ddi_soft_state,
PSARC 2008/754 RealTek RTL8187L USB 802.11b/g Wireless Driver
On Wed, 2008-12-10 at 10:25 +0800, Cecilia Hu wrote: Sebastien Roy wrote: Does the driver have proper support for DDI_SUSPEND in its detach() routine, and for DDI_RESUME in its attach() routine? Given that it's USB, does it even need to for the system to suspend/resume with such a device? Similar question for quiesce() and fast-reboot. All device driver cases should probably include such details to preempt these kinds of questions. Good points and I agree. Those parts should be included in further driver cases. About this one, urtw, AFAIK: . suspend/resume: supports . quiesce and fast-reboot: supports . brussels: supports Thanks for the clarifications. -Seb
PSARC/2008/249 - Packet Interception for the MAC layer
Darren Reed writes:
With the extension of the timer for this project to tbe 10th of December,
I'm updating the materials submmitted to cover changes required to
support the eventual filtering of WiFi packets.
A few quick questions and checks:
1. I assume that net_getlifaddr in the context of a MAC hook
actually returns a MAC layer address, and not an IP address as the
name lif might otherwise suggest. Right?
2. You give the new rule processing as:
[INPUT] - L2 firewall - layer2 IP NAT - layer2 IP firewall -
... - IP NAT - IP firewall - { IP } - IP firewall - IP NAT - ...
- L2 firewall - layer2 IP firewall - layer2 IP NAT - [OUTPUT]
I don't understand why the ordering of operations isn't just
reversed on output. Assuming the input order is correct (and it
appears to me to be right), the L2 firewall element should be
the last operation before [OUTPUT].
3. We're defining these bits of syntax ourselves, and we're expecting
that administrators are going to rely on them for the security of
their systems. Given that, is Volatile the right classification
for the new family ether and layer2 configuration keywords?
4. Why is hpe_hdrinfo void * rather than hook_pkt_info_t *? Void
pointers are mildly evil, as they prevent the compiler and lint
from doing their type-checking jobs. What else would hpe_hdrinfo
point to?
(One very small code review nit: as an argument in a function
definition [dls_devnet_*name2*name], 'const size_t' doesn't do
anything that 'size_t' alone wouldn't 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
Dante: A Socks server and client implementation [PSARC/2008/714 timeout 11/25/2008]
Mayuresh Nirhali writes: I am expecting changes to the proposal that would depend on how we implement privileges in dante, so I believe it is still some more time before we can move ahead with this case. This all sounds good to me, so +1. Not specifically an architectural issue, but the sockd(1M) man page should explain how to turn the service on and off using SMF. -- 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
findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008]
Hello all LSARC members! Please let me know the final decision regarding the packaging structure of findbugs (or more generally of any Java application under OpenSolaris). This LSARC is running already for a long time and I need to move forward with my task. I would be happy to update my LSARC paper with the final solution. Thank you in advance! Petr Slechta Danek Duvall wrote: On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: Looking at this case, which has been sitting for a couple of weeks, I realize that Petr has raised an issue that we need to clarify. If we use links in /usr/share/java to point to the most recent version of each component, and underlying components can be delivered by different packages, then links may get changed and cause things to break. Can we simply assume that IPS handles this situation correctly? If so, are we requiring that all of these FOSS projects going into OpenSolaris use IPS? Those links need each to be delivered exactly once on a system, by just one package. No packaging system can deal with a single file being delivered multiple times by conflicting package developers. I'd suggest that projects either directly use the versioned jar file that's most appropriate for their needs, or install a symlink in a private directory to the jar file they need, and put that in their classpath. Perhaps there are other alternatives, too. Danek
mailwrapper (PSARC/2008/759)
Ceri Davies writes: On Tue, Dec 09, 2008 at 04:27:41PM -0800, Danek Duvall wrote: The whole point is that just about every program which doesn't build in its own mail transmission code calls /usr/lib/sendmail with a standard set of options. Given that, you can put a glorified commandline processor at /usr/lib/sendmail (or /usr/sbin/sendmail, whatev) which then forks off the appropriate / configured real MTA. That's exactly what this case proposes. I've preserved /usr/sbin/sendmail because I don't really know what it's doing there. I don't want to call the mailwrapper binary /usr/sbin/sendmail because it would probably end up being removed by anyone trying to replace sendmail. I don't think we need to try to code around people who deliberately damage their systems. Especially so when the attempt here is unsuccessful -- if someone does munge /usr/lib/sendmail, the new mailwrapper won't be referenced at all because existing programs use the /usr/lib/sendmail path explicitly, so having the mailwrapper bits rotating around on the disk unused won't actually fix anything. A big +1 for delivering a wrapper in place of /usr/lib/sendmail, but not for the introduction of a new /usr/sbin/mailwrapper binary -- it seems exceedingly unlikely that anybody would ever use that new pathname, so it'd serve no purpose. I _think_ your idea here was to allow for a way to people to fix their systems after having damaged them. But such a way already exists -- just reinstall the package. We even include packaging tools to detect when packaged bits are damaged in the first place. We don't need to squirrel away binaries in unused areas in case someone needs to recover them. Simplify: just replace the sendmail path. -- 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
sun4v Platform Independent CPU/Mem FMA events [PSARC/2008/744 FastTrack timeout 12/09/2008]
Tim Haley writes: I am sponsoring this case on behalf of Scott Davenport. This case seeks patch binding for a Solaris 10 Update release. Timeout is 12/09/2008. This case introduces new error report and fault events consumed and generated by the sun4v Platform Independent CPU/Mem DE. +1 ... though ARC review doesn't seem to be adding any value here, and the registry itself is hidden away on the SWAN, so the value of open review is pretty marginal. We probably need a new process for these. -- 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
Cluster Brand Zone Interfaces [PSARC/2008/747 FastTrack timeout 12/10/2008]
Gerald Jelinek writes: I am sponsoring this fast-track (which only records a contract) for Ellard Roush. A copy of the contract is in the case directory and both managers will approve the contract before the timeout. The fast track materials (the email message I'm replying to) should have made it clear that this case establishes a new contract on libzonecfg and associated data structures, ALIAS_* definitions, ZONE_STATE_* and ZONE_IS_* values, and bits from zone.h. In other words, it should have listed the interfaces. Other than that, +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
Cluster Brand Zone Interfaces [PSARC/2008/747 FastTrack timeout 12/10/2008]
Seems straight-forward. +1 On 12/ 3/08 09:36 AM, Gerald Jelinek wrote: I am sponsoring this fast-track (which only records a contract) for Ellard Roush. A copy of the contract is in the case directory and both managers will approve the contract before the timeout. -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
2008/760 Boot configuration Service
I am requiring solaris.system.shutdown as action_authorization and value_authorization for the boot-config services. Attribute solaris.system.shutdown is already in profile Maintenance and Repair, which is what reboot(1M), init(1M) use. I will add the authorization requirements to the man pages. How does this look? Service svc:/system/boot-config:default is enabled by | default. It requires solaris.system.shutdown as | action_authorization and value_authorization. When | fastreboot_default property is set to true, reboot | will behave as reboot -f. | I will make similar modification to the man page for init(1M) if you think the above the changes are sufficient. While that doesn't exactly match the policy, it's nothing to hold up the case for and is a valid thing to do. I'll participate and add a +1. Thanks. Gary..
2008/760 Boot configuration Service
When the service is started or refreshed, uadmin(1M) is invoked with the newly added project private function AD_UPDATE_BOOT_CONFIG. Hummm, seems like we should work offline to see what if any audit impact this new uadmin function has. After recently getting uadmin streightened out wrt audit, I don't want to break it (again). Thankx, Gary..
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 08:11:31AM -0800, Danek Duvall wrote: On Wed, Dec 10, 2008 at 03:59:02PM +, Ceri Davies wrote: I'm specifically trying to make it easy to swap out sendmail, and I think that for anyone unaware of mailwrapper's presence that ls output such as the following: lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq - ../sbin/mailwrapper lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/newaliases - mailwrapper lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/sendmail - mailwrapper lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/lib/sendmail - ../sbin/mailwrapper -r-xr-xr-x 1 root mail 12396 Nov 25 13:44 /usr/sbin/mailwrapper is more instructive and self-descriptive than: lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq - /usr/lib/sendmail lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/newaliases - /usr/lib/sendmail lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/sendmail - /usr/lib/sendmail -r-xr-xr-x 1 root mail 12396 Nov 25 13:44 /usr/lib/sendmail The second gives no clue as to what is going on, while the first should at least get folk thinking about firing up a manual for mailwrapper. I'm okay with this -- I think it's a useful visual clue, and was one answer I thought you might bring up when I asked the question. However, if there's no reason to run mailwrapper directly, do please put it in /usr/lib. sendmail is in /usr/sbin because it is in fact useful from the commandline (indeed, one could probably make the argument it should be in /usr/bin, but that's a whole 'nother can of worms). OK, will move the mailwrapper binary to /usr/lib if consensus rests there. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/4e84cbc0/attachment.bin
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 08:09:15AM -0800, Danek Duvall wrote: On Wed, Dec 10, 2008 at 10:02:58AM +, Ceri Davies wrote: On Wed, Dec 10, 2008 at 11:28:16AM +1100, Darren Reed wrote: John, What's the plan for mailx(1) use of of mailwrapper? Is it intended for mailx(1) to remain as a frontend to sendmail (only) or will it also use mailwrapper(1M)? If it's going to use mailwrapper(1M), then this case looks a bit incomplete as mailx(1) seems to suggest a few bits of its functionality are tied to sendmail... General usage is covered by an entry for mail in mailer.conf. The conv functionality, while alluding to a (undocumented) -U option to sendmail(1M), is implemented internally to mailx(1). I can see -h, -m/metoo and possibly -v/verbose being an issue if a user decides to switch out sendmail; would warnings in the manuals cover this? Not much consolation to the readers of this list, I suppose, but FreeBSD's mailx has allowed metoo and verbose since forever and I don't see a single issue having been reported in the (a few days short of) nine years that mailwrapper has been in place there. How much argument parsing does mailwrapper do, and how much does it pass through to the real MTA? Does it drop anything on the floor? It does no parsing whatsoever. It looks in the config file for an entry matching argv[0] and re-execs with the same arguments, so everything goes straight through; it's really down to the admin to make sure that their replacement MTA has the functionality that they need. I've tried not to break anything with the defaults. Additionally, it's possible to add arguments via the config file; for example you can have a mailq entry of /opt/exim/sbin/exim -bp (although exim does the right thing when invoked as mailq anyway, just an example!). Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/e89e62dc/attachment.bin
mailwrapper (PSARC/2008/759)
Ceri Davies writes: Hmm, no, that's not what I was trying to do. I'm trying to avoid anyone having a WTF? moment when they find yet another pathname for sendmail in /usr/lib that it looks like they'll have to do something with. I think WTF moments are best handled with decent documentation. I'm specifically trying to make it easy to swap out sendmail, and I think that for anyone unaware of mailwrapper's presence that ls output such as the following: lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq - ../sbin/mailwrapper I think the existing hard links function just fine. As an architectural matter, I don't think that the readlink() contents of symlinks in /usr/bin should be considered to be documentation for the system. I understand what you're saying, and that it's an intentional kick in the seat to the admin, but I don't think that's the right way to do this. Why not just make it ../sbin/please-read-the-danged-man-page-already? The second gives no clue as to what is going on, while the first should at least get folk thinking about firing up a manual for mailwrapper. I don't think this is the right way to do it. Update man pages, add new content to docs.sun.com, blog about it, post on netnews, paint skyscrapers, do whatever you want in the way of communication to let folks know about the right way to do things. To make it even more obvious, put /usr/lib/sendmail (the wrapper) into a separate package from the actual sendmail delivery. The wrapper could go in SUNWcsu, for instance. But I don't think it's necessary to encode documentation into the symlinks. Even if users do ignore the new documentation, little is lost: those users get exactly what they want, almost as if they'd used the system properly. -- 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/2008/249 - Packet Interception for the MAC layer
Zhijun Fu writes:
James Carlson wrote:
1. I assume that net_getlifaddr in the context of a MAC hook
actually returns a MAC layer address, and not an IP address as the
name lif might otherwise suggest. Right?
Yes, that's right. For MAC hook we're kind of reusing the same function
though there is actually no lif at MAC layer. :-) I'd like to hear your
suggestions on this.
I've no problem with this. I was just verifying that I understood, as
it doesn't seem to be in the materials.
2. You give the new rule processing as:
[...]
I don't understand why the ordering of operations isn't just
reversed on output. Assuming the input order is correct (and it
appears to me to be right), the L2 firewall element should be
the last operation before [OUTPUT].
It could be a useful feature to combine filtering on L2 and L3
together, or even trigger conditional IP NAT from a L2 filtering rule,
though they are not supported in the current project scope, down the
road we may want to add it, and these features require that L2 firewall
to be processed before those layer2 IP rules.
Also, since the packet is received at MAC layer, it might be more
straight forward to do the parsing and matching from the MAC header,
as we need to parse the MAC header first anyway to locate the IP header
start. It also allows a simpler implementation in IPFilter but that
can be considered an implementation issue anyway.
Would the above make sense?
I'm not sure, but I don't think any of it answers the actual question
I had. You currently have this:
[INPUT] - L2 firewall - layer2 IP NAT - layer2 IP firewall -
... - IP NAT - IP firewall - { IP } - IP firewall - IP NAT - ...
- L2 firewall - layer2 IP firewall - layer2 IP NAT - [OUTPUT]
But that's not entirely symmetric, and I don't see why. I would have
expected it to be:
[INPUT] - L2 firewall - layer2 IP NAT - layer2 IP firewall -
... - IP NAT - IP firewall - { IP } - IP firewall - IP NAT - ...
- layer2 IP firewall - layer2 IP NAT - L2 firewall - [OUTPUT]
That would be symmetric processing: we go through steps A through E on
input, and then E' through A' on output. That's easy to understand.
I don't understand doing A-E on input, and then E', D', A', C', B' on
output, which is what you've documented. Is there a reason for this?
(This is my only real sticking point right now.)
3. We're defining these bits of syntax ourselves, and we're expecting
that administrators are going to rely on them for the security of
their systems. Given that, is Volatile the right classification
for the new family ether and layer2 configuration keywords?
We'll think more about this.
Please just make it Committed.
4. Why is hpe_hdrinfo void * rather than hook_pkt_info_t *?
For MAC layer, it is actually mac_header_info_t *.
Oh ... ok; the documentation should probably make that clearer.
Void
pointers are mildly evil, as they prevent the compiler and lint
from doing their type-checking jobs. What else would hpe_hdrinfo
point to?
The major reason for using void * here, is that hook_pkt_event_t
is a quite general structure that works with all protocols, thus I
feel it is probably not appropriate to use types that specific to
one protocol, e.g. mac_header_info_t is specific to MAC. Also it
could point to other data structure for protocol other than MAC
layer, though there's not such need right now.
I see. I would have used a discriminated type here to make accidents
less likely (an enum + union, or just overlaid structures as is done
with sockaddr), but I guess this is your call.
--
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
BOOST C++ Framework [PSARC/2008/752]
+1 on this case. I haven't read all the Boost documentation, but with its Uncommitted binding, and reliance upon earlier precedent, combined with the fact that the library is a popular C++ building block, I think it would be good for Solaris to have to this integrated. -- Garrett On 12/04/08 11:45, Mark Martin wrote: John Fischer wrote: PSARC, I am sponsoring this case for Stefan Teleman from the SWF group in Menlo Park. The case directory contains this proposal and the BOOST documentation which can be accessed via: http://sac.eng/Archives/CaseLog/arc/PSARC/2008/752/materials/boost-doc-1.37.0/ Theoretically, http://www.opensolaris.org/os/community/arc/caselog/2008/752/materials/boost-doc-1.37.0/ once things synchronize (case dir not yet available at 19:45 UTC)
contract signatures for 2008/688 Sun Cluster TCP/IP Hooks Update
I agree. -Burt Clouse Solaris Cluster James Carlson wrote: In order to finish out this case, I'll need archived signatures from each of the two managers on the 'to' line above. A signature is just an email message saying I agree, and the reply-to for this message has been set to psarc-ext at sun.com, which is where they need to go for archiving. A copy of the contract (for your review) is below. @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2008/688-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: OS/Net Department or Group: Networking Bugster Product/Category/SubCategory: kernel/tcp-ip Responsible Manager: Zhaozhou Li 3. The CONSUMER is identified by the following: Product or Bundle: Sun Cluster Consolidation: Sun Cluster Department or Group: Sun Cluster Bugster Product/Category/SubCategory: suncluster/suncluster/networking Responsible Manager: Burt Clouse 4. The INTERFACES are: cl_inet_connect2 Project Private cl_inet_isclusterwide Project Private cl_inet_ipidentProject Private cl_inet_getspi Project Private cl_inet_checkspi Project Private cl_inet_deletespi Project Private cl_inet_idlesa Project Private cl_inet_listen Project Private cl_inet_unlisten Project Private cl_inet_disconnect Project Private cl_tcp_walk_list Project Private cl_inet_bind Project Private cl_inet_unbind Project Private All are described in PSARC 2008/688. 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: 2008/688 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: Interfaces will be changed only on Minor release boundaries, except for mutually agreed-on bug fixes. Changes can be requested by either party, with the understanding that the SUPPLIER can request resources from CONSUMER to implement the changes. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: CONSUMER will perform regression tests and file bugs as appropriate. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The materials for this case are the only documentation supplied. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: CONSUMER shall perform integration testing. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: By mutual consent.
findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008]
John Plocher wrote: On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers tom.childers at sun.com wrote: ... then links may get changed and cause things to break. We asked the team to adopt the convention established for junit, LSARC/ 2008/633, similar to /usr/lib: /usr/share/lib/java/junit.jar link to most recent version /usr/share/lib/java/junit-4.5.jar /usr/share/lib/java/junit-3.8.2.jar ...etc. However, if they place all the findbugs pieces, like annotations-1.3.4.jar, in /usr/share/lib/java, then we have the situation that multiple projects who require and deliver the same component can overwrite each other. annotations.jar could be changed to link to a different version, breaking the functionality of something that is already installed. Shouldn't those somethings depend directly on the versioned item and NOT on the convenience link? That is, if I depend on junit, I should either A) link to /usr/share/lib/java/junit.jar IFF the interface stability I care about is Committed, or B) link to /usr/share/lib/java/junit-4.5.jar if the interface stability is less stable Is there case precedent that indicates that all libraries should be versioned when installed? What happens for consumers of various version of: dom4j.jar, jaxen.jar, jsr-305.jar, et al listed there - presumably those won't be symlinks? Given the amount of java applications and scaffolding that's in the project pipeline, are we heading towards java jar hell?
BOOST C++ Framework [PSARC/2008/752]
John Fischer John.Fischer at sun.com writes: This project proposes to include the BOOST C++ Framework within a Minor release of Solaris. BOOST allows for Parallel versions to be installed on a system. This project will install BOOST into /usr/include/boost/Major.Minor.Micro and /usr/lib with the library SONAME corresponding to the Major/Minor/Micro name scheme. BOOST depends upon the previous Standard C++ Library provided by the platform specific C++ Compliation and Run-Time Environment. shouldn't this be part of the proposal proper? I think at least the detailed library names belong there. Besides, is it really necessary to use Major/Minor/Micro in the SONAMEs? Do the libraries really change incompatibly with every micro release? This way, one has to accumulate many library versions over time. Same question for the headers. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Cluster Brand Zone Interfaces [PSARC/2008/747 FastTrack timeout 12/10/2008]
James Carlson wrote: Gerald Jelinek writes: I am sponsoring this fast-track (which only records a contract) for Ellard Roush. A copy of the contract is in the case directory and both managers will approve the contract before the timeout. The fast track materials (the email message I'm replying to) should have made it clear that this case establishes a new contract on libzonecfg and associated data structures, ALIAS_* definitions, ZONE_STATE_* and ZONE_IS_* values, and bits from zone.h. In other words, it should have listed the interfaces. Other than that, +1. James, Thanks for looking at this. Did you want Ellard to make any changes to the materials before I close this case? I can leave it open for now, if you do. Thanks again, Jerry
2008/688 Sun Cluster TCP/IP Hooks Update
On 12/03/08 08:06, James Carlson wrote: I'm restarting the timer on this fast-track for Huafeng Lu and the Sun Cluster team. The changes from the last go-around include removing the version number string and adding a netstack ID and a flexible void * argument for future expansion, and the contract (contract-01) has been updated. The timer is set to 12/10/2008. what about the Sun Cluster hooks for SCTP ? Kais.
SPARC support for AST graphics [PSARC/2008/757 FastTrack timeout 12/16/2008]
Yes, the kernel code is SPARC-specific. For example, SPARC does not have the x86-style inb and outb instructions. Access to the chip's I/O space is needed to setup memory-mapped accessibility. The I/O space can be reached from the Solaris kernel, but not from useland. -- Eric On Dec 9, 2008, at 6:30 PM, Edward Shu wrote: Neal Pollack : On 12/09/08 14:15, Eric Sultan wrote: Neal Pollack wrote: ... At a time of pressure to control costs, why is this not common code? Why are we setting up a sparc branch and an existing x86 branch? Or are the two groups working together to merge this support in a common driver (add support for sparc to the existing x86 driver and place it in a common branch of the source tree)? We aren't setting up a separate code branch. The SPARC code will be in the common code base, and that base will be modified to support SPARC as well as x86. During the development cycle, the SPARC code is separate, but it will be merged into the existing Xorg code. Will the kernel code be in X86 system? I think the kernel code may be SPARC specific. -- Eric excellent, thanks. -- Best Regards, Ming. -- -Edward Shu -Solaris x86 Engineering, Sun Microsystems -Blog: http://blogs.sun.com/sming56/ -tele: +86-10-62673100 __
SPARC support for AST graphics [PSARC/2008/757 FastTrack timeout 12/16/2008]
OK, quiesce/unquiesce may make sense for post-Solaris 10 systems. If it were made a part of Solaris 10 at some time in the future, I'd use #pragma weak, testing the waters for some proc (ddi_quiesce_not_needed, for example). I'm not a fan of #pragma weak, and it's not an issue anyway since quiesce/unquiesce isn't part of the Solaris 10 landscape. -- Eric On Dec 9, 2008, at 9:07 PM, Garrett D'Amore wrote: Randy Fishel wrote: On Tue, 9 Dec 2008, Eric Sultan wrote: Randy Fishel wrote: As Seb sort of implied in another case, quiesce() is also a required interface, so it is expected that this project will also implement this entry point, unless it provides equivilent information as would be expected for non-support of DDI_SUSPEND/DDI_RESUME. Quiesce? It doesn't show up in my copy of Writing Device Drivers. A new interface, I presume, and not one currently offered in any of the other Sun SPARC graphics device drivers. I'll look into quiesce(), but I'm pretty sure that it wouldn't be implemented in Solaris 10 drivers, unless they're equipped with a #pragma weak construct to determine whether it's available. Is #pragma weak an acceptable way of determining things like this? Part of the Fast Reboot project: PSARC/2008/382. This is a recent requirement, and I don't expect it will show up in S10, and is an addition to the dev_ops structure. I believe implementing *this* is higher priority (or should be) than SUSPEND/RESUME for this particular device driver. (Rationale: servers need to reboot quickly because they care more about high uptime numbers. But servers rarely are configured to suspend/resume -- the feature is much more generally useful on desktops and laptops. And, clearly, this driver is intended for servers, not for workstation class hardware.) The good news is that quiesce is pretty close to trivial for drivers to implement. All you have to do is put your hardware in a safe for a future reset state... all interrupts and DMA mastering disabled, and ready to be used by another instance of the operating system. It might even be possible to use ddi_quiesce_not_needed() if your device doesn't use DMA mastering or interrupts. (E.g. a simple memory mapped framebuffer wouldn't need to do anything.) You don't have to worry about locking either, because the system is guaranteed to be single threaded when quiesce is called. -- Garrett Randy -- Eric
2008/688 Sun Cluster TCP/IP Hooks Update
Kais Belgaied writes: On 12/03/08 08:06, James Carlson wrote: I'm restarting the timer on this fast-track for Huafeng Lu and the Sun Cluster team. The changes from the last go-around include removing the version number string and adding a netstack ID and a flexible void * argument for future expansion, and the contract (contract-01) has been updated. The timer is set to 12/10/2008. what about the Sun Cluster hooks for SCTP ? The specification sent out for review says this: talk to external servers. Note: this proposal only handles TCP and UDP; SCTP is beyond its scope. I assume that's a future project, if SCTP is to be supported within Sun Cluster at all. (Just like IPv6, it'd likely require non-trivial changes to the Sun Cluster code to do 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
2008/688 Sun Cluster TCP/IP Hooks Update
On 12/10/08 09:32, James Carlson wrote: The specification sent out for review says this: talk to external servers. Note: this proposal only handles TCP and UDP; SCTP is beyond its scope. I assume that's a future project, if SCTP is to be supported within Sun Cluster at all. (Just like IPv6, it'd likely require non-trivial changes to the Sun Cluster code to do it.) OK. +1 Kais
ddi_ssoft_state(9F) and ddi_isoft_state(9F) [PSARC/2008/755 FastTrack timeout 12/17/2008]
After talking with Ed, we have converged. He suggested that the spec should be updated to replace the proposed ddi_ssoft_state_init(9F) 'hash_sz' argument with an 'n_items' hint-type argument (like ddi_soft_state(9F)) to avoid exposing details of a modhash implementation below. This change to a 'hint' facilitates the implementation switching from a modhash to an avl tree if performance becomes an issue. I still need to talk more with Garret. If that does not occur before/at PSARC today, we will need to extend the timer. In either case a new spec will be required. -Chris Hi Ed hey chris, the current ddi soft state interfaces are special in my mind because i thought they were designed to be fast. (note that i wasn't around for the original design, so my opinion is based off the implmentation.) their implementation uses direct array indexing, avoids locking, and avoids free memory, all seemingly in the name of soft state lookup speed. i guess i'm worried that other people may be making the same assumptions about the performance of the ddi soft state interfaces, and these assumptions don't really carry over to the new interfaces since they are really a thin wrapper around modhash. Yes, performance is an issue for interfaces used in the per-IO code path. For the intended use case, the proposed ddi_ssoft_state will not be 'directly' involved in the performance path. In the intended use case, the performance path 'indirectly' gains access to the target-port granularity ddi_ssoft_state via a private pointer maintained in the finer-grained target-port,lun per-scsi_device(9S) hba private soft state (PSARC/2008/675). At tran_tgt_init(9E) time of a scsi_device(9S), the hba driver is expected to ddi_ssoft_state_get(9F) the coarser target-port softstate, and increment a private target-port softstate reference count to account for storing a target-port softstate pointer in the finer-grained per-scsi_device(9S) hba private softstate. hence, i'd rather see something more straitforward, like some version/subset of the modhash interfaces promoted to public, or some new ddi*hash* interfaces. I want the ability to say its a softstate, but you feed it strings instead of integers. With that simple statement, I believe that anyone who has written a solaris driver would get it. I don't want to loose that. Keep in mind that any part of the device tree that has multiple complex addressing levels compressed into a single devinfo node unit-address (@component-a,component-b,component-c) will face this problem - which is why I thought the ddi_ssoft_* prefix was warranted. The solution to performance path issues will likely involve a private ref_count approach similar to our use case above. If the above explanation is insufficient, to make progress, I am willing to change the interface prefix from ddi_ssoft_state_* to scsi_taddr_ssoft_state_*, indicating a more restricted use case that meets immediate needs. Thanks -Chris from ddi_ssoft_state(9F) proposed man page... int ddi_ssoft_state_init(ddi_ssoft_state **state_p, size_t size, size_t hash_sz); hash_szThe number of hashed lists which will be allocated; zero is not allowed. There is a performance .vs. space tradeoff in the selection of a hash_sz value: for 'n' soft state structures, on average each ddi_ssoft_state_get will need to traverse 'n'/hash_sz/2 entries to locate the requested soft state structure. Change to int ddi_ssoft_state_init(ddi_ssoft_state **state_p, size_t size, size_t n_items); ... n_itemsA hint of the number of items which will be allocated.
BOOST C++ Framework [PSARC/2008/752]
Rainer Orth wrote: John Fischer John.Fischer at sun.com writes: This project proposes to include the BOOST C++ Framework within a Minor release of Solaris. BOOST allows for Parallel versions to be installed on a system. This project will install BOOST into /usr/include/boost/Major.Minor.Micro and /usr/lib with the library SONAME corresponding to the Major/Minor/Micro name scheme. BOOST depends upon the previous Standard C++ Library provided by the platform specific C++ Compliation and Run-Time Environment. shouldn't this be part of the proposal proper? I think at least the detailed library names belong there. Detailed library names, with API documentation are clearly indicated in the ARC Materials (documentation). There is a chapter for each and every BOOST Library. Besides, is it really necessary to use Major/Minor/Micro in the SONAMEs? Yes, because this is the software construction mechanism devised by the BOOST Developers, and it is the mechanism currently followed by every single distribution of BOOST. Half of BOOST libraries don't even have a SONAME, because they aren't delivered as shared library objects, but as header + source files. I'd be interested in learning why we (SMI) should deviate from mainstream. Do the libraries really change incompatibly with every micro release? Given that BOOST has taken considerable care in designing a construction and delivery mechanism which permits non-conflicting coexistence of several versions of BOOST, this seems to have been done for the purpose of avoiding [ mitigating ] incompatibilities between BOOST releases. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
PSARC/2008/249 - Packet Interception for the MAC layer
There is a rather long discussion about the design and some architectural questions in parallel, outside this alias. I was hoping that discussion converges before the case times out. Darren, this case needs to be put back in waiting need spec, at least until the variety of changes being proposes over the last week settle. Kais
2008/688 Sun Cluster TCP/IP Hooks Update
James Carlson writes: I'm restarting the timer on this fast-track for Huafeng Lu and the Sun Cluster team. The changes from the last go-around include removing the version number string and adding a netstack ID and a flexible void * argument for future expansion, and the contract (contract-01) has been updated. The timer is set to 12/10/2008. This fast-track request was approved during ARC business at today's PSARC meeting. I'm leaving it open until I can gather contract signatures. -- 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
BOOST C++ Framework [PSARC/2008/752]
Stefan Teleman wrote: Given that BOOST has taken considerable care in designing a construction and delivery mechanism which permits non-conflicting coexistence of several versions of BOOST, this seems to have been done for the purpose of avoiding [ mitigating ] incompatibilities between BOOST releases. More specifically, this: http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Removed --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
2008/760 Boot configuration Service
Gary Winiger wrote: When the service is started or refreshed, uadmin(1M) is invoked with the newly added project private function AD_UPDATE_BOOT_CONFIG. Hummm, seems like we should work offline to see what if any audit impact this new uadmin function has. After recently getting uadmin streightened out wrt audit, I don't want to break it (again). In PSARC business today, we confirmed this is an implementation note and that Sherry and Gary should talk to confirm there are no problems. PSARC feels the case has nearly converged, and doesn't need to wait the full week for approval, though was hesitant to approve with less than 24 hours of review time during PSARC business today. Per their request, I've changed the timeout to 12/12/2008. thanks, liane
ddi_ssoft_state(9F) and ddi_isoft_state(9F) [PSARC/2008/755 FastTrack timeout 12/17/2008]
On 12/10/08 09:40, Chris Horne wrote: After talking with Ed, we have converged. He suggested that the spec should be updated to replace the proposed ddi_ssoft_state_init(9F) 'hash_sz' argument with an 'n_items' hint-type argument (like ddi_soft_state(9F)) to avoid exposing details of a modhash implementation below. This change to a 'hint' facilitates the implementation switching from a modhash to an avl tree if performance becomes an issue. I still need to talk more with Garret. If that does not occur before/at PSARC today, we will need to extend the timer. In either case a new spec will be required. The case was let run. There were other objections to the originally proposed names. Garrett's Opinion I still believe calling this soft state violates the principle of least surprise, because soft state to me is a one-per-device-instance thing, which is not the intended use. If the project team is willing to call these interfaces ddi_named_state_xxx Then I can give the project a +1 without major reservations. [ as an aside, I think an even better/simpler approach would be something more parallel to ddi_set_private/get_private, like this: ddi_set_named_private(), ddi_get_named_private()... ] With ddi_str_soft_state_xxx, I am less happy. The name is both more awkward to use, and seems a bit more vague. (Is the state a string? Is it really soft state -- what is soft state anyway? The definition isn't clear, and your new usage sort of flies in the face of existing convention, in at least my opinion.) That said, if you can find at least one other member to give the project a +1 with ddi_str_soft_state_xxx, I'll abide the decision and not argue it further. /Garrett's Opinion -- Garrett -Chris Hi Ed hey chris, the current ddi soft state interfaces are special in my mind because i thought they were designed to be fast. (note that i wasn't around for the original design, so my opinion is based off the implmentation.) their implementation uses direct array indexing, avoids locking, and avoids free memory, all seemingly in the name of soft state lookup speed. i guess i'm worried that other people may be making the same assumptions about the performance of the ddi soft state interfaces, and these assumptions don't really carry over to the new interfaces since they are really a thin wrapper around modhash. Yes, performance is an issue for interfaces used in the per-IO code path. For the intended use case, the proposed ddi_ssoft_state will not be 'directly' involved in the performance path. In the intended use case, the performance path 'indirectly' gains access to the target-port granularity ddi_ssoft_state via a private pointer maintained in the finer-grained target-port,lun per-scsi_device(9S) hba private soft state (PSARC/2008/675). At tran_tgt_init(9E) time of a scsi_device(9S), the hba driver is expected to ddi_ssoft_state_get(9F) the coarser target-port softstate, and increment a private target-port softstate reference count to account for storing a target-port softstate pointer in the finer-grained per-scsi_device(9S) hba private softstate. hence, i'd rather see something more straitforward, like some version/subset of the modhash interfaces promoted to public, or some new ddi*hash* interfaces. I want the ability to say its a softstate, but you feed it strings instead of integers. With that simple statement, I believe that anyone who has written a solaris driver would get it. I don't want to loose that. Keep in mind that any part of the device tree that has multiple complex addressing levels compressed into a single devinfo node unit-address (@component-a,component-b,component-c) will face this problem - which is why I thought the ddi_ssoft_* prefix was warranted. The solution to performance path issues will likely involve a private ref_count approach similar to our use case above. If the above explanation is insufficient, to make progress, I am willing to change the interface prefix from ddi_ssoft_state_* to scsi_taddr_ssoft_state_*, indicating a more restricted use case that meets immediate needs. Thanks -Chris from ddi_ssoft_state(9F) proposed man page... int ddi_ssoft_state_init(ddi_ssoft_state **state_p, size_t size, size_t hash_sz); hash_szThe number of hashed lists which will be allocated; zero is not allowed. There is a performance .vs. space tradeoff in the selection of a hash_sz value: for 'n' soft state structures, on average each ddi_ssoft_state_get will need to traverse 'n'/hash_sz/2 entries to locate the requested soft state structure. Change to int ddi_ssoft_state_init(ddi_ssoft_state **state_p, size_t size, size_t n_items); ... n_itemsA hint of the number of items which will be allocated.
BOOST C++ Framework [PSARC/2008/752]
Rainer Orth wrote: Garrett D'Amore writes: If I understand correctly, Stefan's response is that minor/micro versions are required because there *can* be incompatible changes in the Boost libraries from upstream. That is to say, Boost doesn't guarantee binary compatibility, but instead requires developers to code to a specific release. That's what I now found in the BOOST FAQ at http://www.boost.org/users/faq.html (How can the Boost libraries be used successfully for important projects?) Some postings on their mailing lists indicate that their track record for compatiblity isn't particularly good, even silently breaking compatibility in micro releases (which seem to be rare, though). While this may seem unfortunate, its the way Boost developers work, I guess. Its not particularly worse, IMO, than the other problems inherent in using C++ when you care about compatibility. Seems so, yes. This happens mainly because BOOST is, first and foremost, a language research project. The intent is to discover and provide implementations for new language idioms and techniques, and as such, maintaining compatibility takes a second seat. The consistency and compatibility aspect is addressed by including BOOST components in the Language Standard, at which point these components acquire the expected Interface Stability Classification commitment. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 08:03:18PM +, Ceri Davies wrote: On Wed, Dec 10, 2008 at 11:10:59AM -0500, James Carlson wrote: Ceri Davies writes: I'm specifically trying to make it easy to swap out sendmail, and I think that for anyone unaware of mailwrapper's presence that ls output such as the following: lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq - ../sbin/mailwrapper I think the existing hard links function just fine. Hard links can't really be used as people aren't supposed to install their own stuff into /usr, apparently. Sorry, I was thinking of something else entirely (not even this OS) there. However, it might be worth noting that mailwrapper is actually a completely generic wrapper and I have therefore avoided the getexecname only works with hard links problem by not using it. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/34894738/attachment.bin
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 08:03:18PM +, Ceri Davies wrote: On Wed, Dec 10, 2008 at 11:10:59AM -0500, James Carlson wrote: As an architectural matter, I don't think that the readlink() contents of symlinks in /usr/bin should be considered to be documentation for the system. I understand what you're saying, and that it's an intentional kick in the seat to the admin, but I don't think that's the right way to do this. I guess that depends on whether you think users are likely to do ls -l /usr/lib/sendmail -- I do, but that may be because I do that sort of thing often. You're probably right. If there are no objections, I can install the mailwrapper binary at /usr/lib/sendmail. I think that makes zero difference from a getting-the-docs-right point of view, but having /usr/lib/sendmail as a symlink to mailwrapper sure does make a difference: it gives those users who would do ls -l /usr/lib/sendmail a mega-clue as to what manpage to read. Other users are in no different a position than if the symlink had been the other way around. What does that mean for the manpages, specifically wrt section numbers for mailwrapper? sendmail is in 1M, but I think something like this should be in section 1, since mailwrapper is not really and administrative tool, at least not when used to send mail.
mailwrapper (PSARC/2008/759)
Ceri Davies writes: On Wed, Dec 10, 2008 at 11:10:59AM -0500, James Carlson wrote: I'm specifically trying to make it easy to swap out sendmail, and I think that for anyone unaware of mailwrapper's presence that ls output such as the following: lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq - ../sbin/mailwrapper I think the existing hard links function just fine. Hard links can't really be used as people aren't supposed to install their own stuff into /usr, apparently. Correct, they're not. (They often do, but as long as they don't tromp all over the documented filesystem(5) interfaces, and are just doing things like /usr/local, there's no problem.) As an architectural matter, I don't think that the readlink() contents of symlinks in /usr/bin should be considered to be documentation for the system. I understand what you're saying, and that it's an intentional kick in the seat to the admin, but I don't think that's the right way to do this. You're probably right. If there are no objections, I can install the mailwrapper binary at /usr/lib/sendmail. What does that mean for the manpages, specifically wrt section numbers for mailwrapper? I would do something like this: - move the existing sendmail(1M) to sendmail-mta(1M) or sendmail(1MTA) (or whatever's most appropriate for the places where the MTAs will be hidden). - create a new sendmail(1M) (with a man page link as mailwrapper(1M)) that describes the wrapper interface and points to the places where the per-MTA descriptions can be found. Leaving the existing sendmail(1M) in place (which documents the /usr/lib/sendmail), but changing /usr/lib/sendmail to be a symlink off in some other direction sounds like a confusing result to me. -- 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
mailwrapper (PSARC/2008/759)
You're probably right. If there are no objections, I can install the mailwrapper binary at /usr/lib/sendmail. What does that mean for the manpages, specifically wrt section numbers for mailwrapper? Except... This thing *isn't* sendmail, it is a placeholder/proxy for the hardcoded exec() strings stuffed into other applications. What should the man pages say? This thing called sendmail isn't really sendmail, it is a proxy for the real sendmail, which now lives over -there-? As it is now, the man page for mailwrapper does a pretty good job of describing things. Without the mailwrapper name (which is how the rest of the world identifies this feature), isn't this just asking for confusion - yet another place where OpenSolaris is arbitrarily different in a small way from the rest of the *nix world? doesn't being the same as other places trump but we could have invent something better if we tried? -John
mailwrapper (PSARC/2008/759)
Nicolas Williams writes: On Wed, Dec 10, 2008 at 08:03:18PM +, Ceri Davies wrote: You're probably right. If there are no objections, I can install the mailwrapper binary at /usr/lib/sendmail. I think that makes zero difference from a getting-the-docs-right point of view, but having /usr/lib/sendmail as a symlink to mailwrapper sure does make a difference: it gives those users who would do ls -l /usr/lib/sendmail a mega-clue as to what manpage to read. That's precisely the problem I was pointing out. The sendmail(1M) man page documents the /usr/lib/sendmail interface. If that's to become mailwrapper (and I agree it should!), then it's _wrong_ to have that man page document something other than mailwrapper. You're assuming that users will do ls -l /usr/lib/sendmail, see the mailwrapper link, and then stumble onto the mailwrapper(1M) man page. I'm assuming that the user invokes man sendmail first, and we tell him exactly what the interface does (it's not sendmail.org anymore), and that we point him in the right direction from there. -- 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
mailwrapper (PSARC/2008/759)
Nicolas Williams writes: On Wed, Dec 10, 2008 at 03:49:34PM -0500, James Carlson wrote: The sendmail(1M) man page documents the /usr/lib/sendmail interface. If that's to become mailwrapper (and I agree it should!), then it's _wrong_ to have that man page document something other than mailwrapper. Yes, but everyone knows what sendmail is, and mailwrapper is something else. What should happen here is that the sendmail(1M) manpage should prominently reference the mailwrapper manpage. Really? What then documents /usr/lib/sendmail? I'm assuming that the user invokes man sendmail first, and we tell him exactly what the interface does (it's not sendmail.org anymore), and that we point him in the right direction from there. Except that sendmail is still sendmail No, it's not. This project explicitly moves the real sendmail somewhere else, so that the wrapper can invoke it. -- not /usr/lib/sendmail, but when you run man sendmail how's man(1) to know that you mean the sendmail in /usr/lib instead of the Real Sendmail? One way to do this would be to have a separate page that documents the real sendmail. The mailwrapper change should create a new place for the alternative MTAs it invokes to live, and that's a fine place to document each of them. I don't like having sendmail(1M) list /usr/lib/sendmail and then tell you about something that isn't actually there, or is only sometimes there depending on configuration options. That's fine for the original design of mailwrapper -- a simple light hack that users can apply to their own systems, where the user knows what he's done to the system -- but makes no sense at all for a system that's supposed to be delivered without a pile of blue wires on top. -- 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
IB Support for Relaxed Ordering [PSARC/2008/762 FastTrack timeout 12/17/2008]
Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: IB Support for Relaxed Ordering 1.2. Name of Document Author/Supplier: Author: Lida Horn 1.3 Date of This Document: 10 December, 2008 4. Technical Description PSARC members: please at least look at the **IMPORTANT NOTE** below and comment. If this fasttrack needs to be derailed, having an early indication is appreciated, so we don't waste time. IB Support for Relaxed Ordering --- 4.1 Background Certain Sun platforms have introduced support for PCI Relaxed Ordering (RO) for increased performance (see PSARC/2006/157). In theory, if InfiniBand (IB) applications are written as recommended by the IB specification [1] (that is to use IB completions to understand when operations are done), the usage of RO should have no impact on how IB applications are written. However, for many years, Message Passing Interface (MPI) implementations for IB have knowingly violated these recommendations in pursuit of maximum performance (which is considered very important in this segment of the HPC market). In particular, it has been a common practice to rely on memory polling where MPI waits for the last bytes in a transfer to flip to know when an operation is done. (This also relies on knowing which bytes will be written last.) This practice shaves off the time necessary to deliver the IB completion. Of course, RO can create a problem with memory polling, since the last transfer bytes are not necessarily delivered last (when DMA operations consist of multiple transfer units). This situation introduces the potential for corruption. It should be pointed out that exposure to this potential danger hasn't been a problem because IB cards were not certified on RO platforms. However, now that we are trying to bring IB MPI support to RO platforms, this problem must be confronted. This case introduces mechanisms for IB memory polling clients to operate safely in the face of PCI Relaxed Ordering. 4.2 Proposal This proposal makes changes/additions to two components used by memory polling IB clients: uDAPL (PSARC/2003/145 and follow-on cases) and the InfiniBand Transport Framework (IBTF, PSARC/2002/132 and follow-on cases). In uDAPL, changes are made to the client interface. In IBTF, changes are made to the Transport Interface (TI) for ULPs and Channel Interface (CI) for HCA drivers. The IBTF changes are part of the v3 IBTF ABI first introduced in PSARC/2008/630. All interface changes and additions in this proposal have a micro/patch binding, however note the issue with uDAPL interfaces below. IBTF Transport Interface (ON Consolidation Private) ibt_mr_flags_t: IBT_MR_DISABLE_RO flag - disable RO on registration IBTF Channel Interface (ON Consolidation Private) ibt_mr_flags_t: IBT_MR_DISABLE_RO flag - disable RO on registration uDAPL changes (incompatible change to Committed interface, see below) dat_ia_open(): RO_AWARE_ prefix for ia_name_ptr dat_lmr_create(): new DAT_MEM_TYPE_SO_VIRTUAL memory type **IMPORTANT NOTE**: both dat_ia_open() and dat_lmr_create() are part of the published standards for uDAPL [2]. The original uDAPL case (PSARC/2003/145), implementing uDAPL 1.1, exports these interfaces as Standard, which now translates to Committed. In PSARC/2004/399, our uDAPL was upgraded to 1.2. Usually a change to these interfaces could only occur in a major release. However, as noted in the Interface Taxonomy, exemptions are possible for reasons such as possible data corruption inherent in the interface, which we believe to be the case here. We believe the impact of this incompatible change to be mitigated for two reasons: * this issue only arises on RO platforms not previously certified for IB cards, therefore uDAPL will continue to work as before on previously supported platforms; only new usage on RO platforms will have to contend with this issue * the limited current usage of uDAPL (almost exclusively a few MPIs); most OS bypass clients now use Open Fabric User Verbs (which Sun also intends to eventually transition to) -- for the same reasons, it is unlikely we could get a change made to the uDAPL interface (because of the declining interest in uDAPL, the DAT Collaborative no longer meets to continue uDAPL spec development) Copies of all modified/added man pages are in the materials directory (see section 4.3 below). Change bars highlight modifications. A. uDAPL RO-Aware Clients One key concept is for uDAPL to understand when (newer) clients have code to handle RO platforms (i.e. are RO Aware). Clients signal this awareness by prefixing the interface adapter name argument to dat_ia_open() with the string RO_AWARE_. Clients which do not do this (legacy ones) are assumed to be unaware of RO issues. uDAPL code determines whether a
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 12:48:50PM -0800, John Plocher wrote: You're probably right. If there are no objections, I can install the mailwrapper binary at /usr/lib/sendmail. What does that mean for the manpages, specifically wrt section numbers for mailwrapper? Except... This thing *isn't* sendmail, it is a placeholder/proxy for the hardcoded exec() strings stuffed into other applications. What should the man pages say? This thing called sendmail isn't really sendmail, it is a proxy for the real sendmail, which now lives over -there-? As it is now, the man page for mailwrapper does a pretty good job of describing things. I really hadn't intended to suggest that man sendmail should show anything other than exactly what it does now. What I was actually asking is what section mailwrapper belongs in if there is no entity named mailwrapper in the system. I personally would prefer to deliver exactly what was originally proposed with the solitary change of moving /usr/sbin/mailwrapper to /usr/lib/mailwrapper. Changing the sendmail manpage in any way, shape or form is not on my agenda, I think it's wrong. This utility is called mailwrapper, not sendmail. Without the mailwrapper name (which is how the rest of the world identifies this feature), isn't this just asking for confusion - yet another place where OpenSolaris is arbitrarily different in a small way from the rest of the *nix world? doesn't being the same as other places trump but we could have invent something better if we tried? While I didn't want to say it, there is a Familiarity card to be played here, unless that only works with Linux apps :) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/64d91928/attachment.bin
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 04:33:08PM -0500, James Carlson wrote: Yes, but everyone knows what sendmail is, and mailwrapper is something else. What should happen here is that the sendmail(1M) manpage should prominently reference the mailwrapper manpage. Really? What then documents /usr/lib/sendmail? Yes, really. The sendmail(1M) manpage. As I wrote, I don't see how man(1) could know which the user wants the manpage for, the real sendmail or the wrapper, when the user runs man sendmail and I think it will be surprising if man sendmail shows the manpage for mailwrapper. Either way the manpage that man sendmail shows will have to have a prominent reference to the manpage that it is not. So perhaps this is just six of one and half a dozen of the other. Except that sendmail is still sendmail No, it's not. This project explicitly moves the real sendmail somewhere else, so that the wrapper can invoke it. That's not what I meant. If I was explicitly looking for the manpage for sendmail, the real sendmail, whatever its name might be, I'd start with man sendmail. -- not /usr/lib/sendmail, but when you run man sendmail how's man(1) to know that you mean the sendmail in /usr/lib instead of the Real Sendmail? One way to do this would be to have a separate page that documents the real sendmail. The mailwrapper change should create a new place for the alternative MTAs it invokes to live, and that's a fine place to document each of them. I don't like having sendmail(1M) list /usr/lib/sendmail and then tell you about something that isn't actually there, or is only sometimes there depending on configuration options. That's fine for the original design of mailwrapper -- a simple light hack that users can apply to their own systems, where the user knows what he's done to the system -- but makes no sense at all for a system that's supposed to be delivered without a pile of blue wires on top. OK, I'm convinced now that either choice is equivalent. I would still prefer that /usr/lib/sendmail be a symlink to mailwrapper because it will give a very strong visual clue to those users who do look at it.
IB Support for Relaxed Ordering [PSARC/2008/762 FastTrack timeout 12/17/2008]
Ted Kim writes: PSARC members: please at least look at the **IMPORTANT NOTE** below and comment. If this fasttrack needs to be derailed, having an early indication is appreciated, so we don't waste time. Ted and I talked this one over at length off-line, so +1 from me. -- 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
mailwrapper (PSARC/2008/759)
On Wed, Dec 10, 2008 at 2:08 PM, Ceri Davies ceri at submonkey.net wrote: I really hadn't intended to suggest that man sendmail should show anything other than exactly what it does now. A good result might be: man sendmail Shows the man page for /usr/sbin/sendmail (aka mailwrapper), which has a reference to the real /usr/lib/sendmail and other MTAs. man -s1M sendmail Shows the real sendmail manpage, with a reference to mailwrapper. man -s1M other MTA program Shows the real whatever MTA, with a reference to mailwrapper Alternatively, you could take a hint from VFS/mount (via the intro(1M) manpage: Because of command restructuring for the Virtual File System architecture, there are several instances of multiple manual pages that begin with the same name. For example, the mount, pages - mount(1M), mount_cachefs(1M), mount_hsfs(1M), mount_nfs(1M), mount_tmpfs(1M), and mount_ufs(1M). In each such case the first of the multiple pages describes the syn- tax and options of the generic command, that is, those options applicable to all FSTypes (file system types). The succeeding pages describe the functionality of the FSType- specific modules of the command. These pages list the com- mand followed by an underscore ( _ ) and the FSType to which they pertain. Note that the administrator should not attempt ... -John
OpenDS Integration into OpenSolaris [ LSARC/2008/691 FastTrack timeout 11/19/2008]
I'm rather late posting to this thread. I just went through the excercise of getting OpenDS working for native LDAP authentication. The process is documented here: http://blogs.sun.com/warren/entry/opensolaris_opends_opensolaris_client_ldap There were quite a few tweaks that needed to be made to OpenDS to get it work (fixing ACIs, importing sample schema). It would be great if the integration did all this stuff out of the box (including creating some sample user/group entries). The process as it stands to get client ldap going is a pain in the ass. Warren -- This message posted from opensolaris.org
OpenDS Integration into OpenSolaris [ LSARC/2008/691 FastTrack timeout 11/19/2008]
Agreed. OpenDS should probably replace the legacy SunDS 5.x stuff. The biggest pain for SA's and companies is that the documentation for configuring native LDAP auth from scratch on Solaris is broken, incomplete, or just plain missing from the JES or Solaris documentation. This is critical if Sun wants people to use their product to retire NIS and NIS+ in the field. It might even be worth while to have some basic and advanced integration for configuring a native LDAP auth server and client for Solaris/Unix. Most of the current Sun documentation focuses on using LDAP for applications, but doesn't really scratch the surface setting it up from scratch for normal login/accounting auth. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: Warren Strange warren.stra...@sun.com To: opensolaris-arc at opensolaris.org Sent: Wednesday, December 10, 2008 6:35:19 PM Subject: Re: OpenDS Integration into OpenSolaris [ LSARC/2008/691 FastTrack timeout 11/19/2008] I'm rather late posting to this thread. I just went through the excercise of getting OpenDS working for native LDAP authentication. The process is documented here: http://blogs.sun.com/warren/entry/opensolaris_opends_opensolaris_client_ldap There were quite a few tweaks that needed to be made to OpenDS to get it work (fixing ACIs, importing sample schema). It would be great if the integration did all this stuff out of the box (including creating some sample user/group entries). The process as it stands to get client ldap going is a pain in the ass. Warren -- This message posted from opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org
sun4v Platform Independent CPU/Mem FMA events [PSARC/2008/744 FastTrack timeout 12/09/2008]
On Wed, 2008-12-10 at 10:27 -0500, James Carlson wrote: Tim Haley writes: I am sponsoring this case on behalf of Scott Davenport. This case seeks patch binding for a Solaris 10 Update release. Timeout is 12/09/2008. This case introduces new error report and fault events consumed and generated by the sun4v Platform Independent CPU/Mem DE. +1 ... though ARC review doesn't seem to be adding any value here, and the registry itself is hidden away on the SWAN, so the value of open review is pretty marginal. We probably need a new process for these. James, Thankssince the timer has expired and Tim's in Germany, would you be able to mark the case as approved? Also, the event registry (in snapshot form) is available publicly via http://www.opensolaris.org/os/project/events-registry/. But don't disagree that there can be some process improvement here. Thanks, -scott
