From gd78059@sac.sfbay.sun.com Mon Jul 6 08:59:09 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n66Fx8mH005004 for ; Mon, 6 Jul 2009 08:59:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n66Ftlk7009589; Mon, 6 Jul 2009 23:59:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMD00I01AWZ0F00@brm-avmta-1.central.sun.com>; Mon, 06 Jul 2009 09:55:47 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMD007JGAWYU280@brm-avmta-1.central.sun.com>; Mon, 06 Jul 2009 09:55:46 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n66FtkJR015608; Mon, 06 Jul 2009 08:55:46 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n66Ftjr0004865; Mon, 06 Jul 2009 08:55:45 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n66FtigT004861; Mon, 06 Jul 2009 08:55:44 -0700 (PDT) Date: Mon, 06 Jul 2009 08:55:44 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200907061555.n66FtigT004861@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7225 I'm submitting the following case on my own behalf. Times out on 7/13/2009. This case seeks patch binding. 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: STREAMS and Character Device Coexistence 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 06 July, 2009 4. Technical Description STREAMS and Character Device Coexistence ---------------------------------------- Background: ----------- There are two different frameworks for device drivers in Solaris -- one that implies a device is a typical character/block device (and hence supports the typical read(2), write(2), etc. entry points), and another that assumes that devices are STREAMs devices and export their entry points via cb_ops. Most device drivers fall firmly into one style (character/block) or the other (STREAMs.) Usually which kind of device the driver acts as is determined by what type of hardware it is. For example, NIC drivers are required to be STREAMs devices in Solaris. Audio devices historically were STREAMs based, although since Boomer (PSARC 2008/318) they are now character devices. Problem: -------- Some devices for one reason or another cannot properly be described as a just character/block or STREAMs. This is a problem that has recurred many times in the author's experience. Some specific examples: * Venus (Sun Crypto Accelerator 4000) -- this device is a NIC, so it must be a STREAMs device. However, for the Crypto framework used at the time (kcl, in Solaris 8) the crypto functionality was expressed via character interfaces. (STREAMs was deemed far to cumbersome for this kind of functionality since a lot of complex structures had to be copied back and forth.) * Audio - to be compatible with the legacy Audio API, audio devices need to be STREAMs devices. But the new style OSS API is character based, and trying to impose STREAMs created a problem where STREAMs queueing semantics resulted in latency that the OSS API could not express to applications (and hence applications lost the ability to perform accurate positioning within the stream.) * Converged IB/networking devices. Devices from some vendors can support either Infiniband or 10GbE functionality, based upon firmware configuration or external influences. The Infiniband functionality and framework was designed to be character/block driven (especially it wants to perform some efficient mmap(2) operations and wants to avoid STREAMs latency) while the 10 gigabit ethernet functionality needs to be based upon STREAMs as part of the GLDv3. The problem here is that Solaris' DDI requires all minor nodes of a single device (dev_info_t) to be either STREAMs or character/block device. There is no way to mix and match. Historial Workarounds: ---------------------- The historical workarounds have varied here. There are two approaches that the author has seen so far: 1) Nexus driver approach. In this approach, the device is a nexus, and separate device drivers for each type of personality are developed. While this works, the problems with it stem from the fact that the nexus framework is very awkward, undocumented, and not available to 3rd parties. It also creates an artifical branch point in the tree, which might not be the way to handle. This approach can get in the way of code sharing. For legacy products, like the converged networking device, making use of this may require substantial rearchitecture of already complex devices and subsystems. 2) Pseudo-driver. A slightly different approach, by using LDI (or legacy equivalents) and a pseudo device, its possible to dynamically create minor nodes of a different device type. The austr device in the audio subsystem was created for this purpose. While it works, and doesn't violate any public DDI, its incredibly awkward, and requires devices to do extra magic outside of the driver to make sure that minor nodes are properly reflected. (For example, the audio framework performs a devfsadm -i austr during early boot to make sure that the instance for this pseudo driver is attached so that it can create and remove minor nodes on demand from the master device.) A similar approach was used in the Solaris 8 software for Venus -- the crypto minor nodes were owned by the crypto framework, rather than the physical device instance. As a result of this, the framework needed to ensure that its minor node was always ready, and the drivers exported the ddi-no-autodetach and ddi-forceattach properties to make sure that hardware associated with the crypto was always ready to go. Proposed Solution: ------------------ We'd like to propose that it should be possible for a device driver to export minor nodes of both types (STREAMs and character/block devices.) The main challenge here is deciding which entry points to use (the cb_ops or the streamtab ones). The solution is relatively simple. At open(9e) time, the STREAMS point shall be allowed to return a special errno (already defined), ENOSTR, to indicate that the minor node supplied is not associated with STREAMS, but rather that the specfs framework should retry the open using the character based open(9e). (As an aside, if some STREAMS entry point did return ENOSTR without intending this new semantic, the framework will call nodev() -- which is what STREAMS drivers are supposed to use for the cb_open() entry point -- returning ENODEV back to the calling application. While the semantic change is unfortunate, since ENOSTR is not a documented or used return code from open(9e) today, it should not be viewed as a problem.) All other specfs entry points can simply change their checks for STREAMSTAB(major) to a check for an already open stream. For example, in spec_write(): if (STREAMSTAB(getmajor(dev))) { ASSERT(vp->v_type == VCHR); smark(sp, SUPD); return (strwrite(vp, uiop, cr)); } Would be rewritten as: if (vp->v_stream != NULL) { ASSERT(vp->v_type == VCHR); smark(sp, SUPD); return (strwrite(vp, uiop, cr)); } (Note that strwrite already has an ASSERT(vp->v_stream) as its first line of executable code other than variable assignment). Minor Number Management: ------------------------ Note that while the above problem solves the situation generally, there is a problem with frameworks where the framework manages the minor number space. The GLDv3 is one such framework. Resolving this problem will need to be done on a case by case basis, and falls outside of the scope of this case. However, we would recommend future creators of such frameworks provide for a mechanism for device drivers to control their own minor number space. It seems short sighted to assume that a single framework will reasonably be able to know all the ways in which a device might want to use minor numbers. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From edward.pilatowicz@sun.com Mon Jul 6 13:58:49 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n66KwmkM015702 for ; Mon, 6 Jul 2009 13:58:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n66KwhQb017550 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 7 Jul 2009 04:58:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMD00403OXWY300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 06 Jul 2009 14:58:44 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMD005VPOXWFZB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 06 Jul 2009 14:58:44 -0600 (MDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n66Kwh5N018737; Mon, 06 Jul 2009 13:58:43 -0700 (PDT) Date: Mon, 06 Jul 2009 13:58:43 -0700 From: Edward Pilatowicz Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <200907061555.n66FtigT004861@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <20090706205843.GL993184@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2181 hey garrett, some quick questions. - this new functionality seems to be tied to the vnode/specfs layer which is how userland and the ldi accesses devices, so presumably this streams to cb_ops fall back behaviour will be supported for both userland and ldi based device access? (i assume so.) - will this fall back behaviour be supported for CLONE_DEV based minor nodes? (i assume not.) - once a device minor node is successfully opened, the underlying driver must have decided on streams or cb_ops based access. so: - if it decided on cb_ops accesses, will subsequent opens go directly to the cb_ops open routine? (i assume so.) - if it decided on streams access, is it valid for subsequent open calls to return ENOSTR? (i assume not.) - device open/close exclusion guarantees are implemented separately for streams and cb_ops based access. presumably these guarantees will still apply to devices that can switch between streams and cb_ops based accesses? (in which case i guess the properties defined in PSARC/2007/310 will be applicable to streams based drivers.) - do you anticipate having individual minor device nodes that switch between cb_ops and steams based access? - instead of having the streams open entry point return ENOSTR to fall back to cb_ops, did you consider adding a new flag to ddi_create_minor_node() so that a driver could specify the desired access semantics of a given minor node? - what is the commitment level of this new ENOSTR interface? ed On Mon, Jul 06, 2009 at 08:55:44AM -0700, Garrett D'Amore - sun microsystems wrote: > I'm submitting the following case on my own behalf. Times out on 7/13/2009. > This case seeks patch binding. > > 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: > STREAMS and Character Device Coexistence > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 06 July, 2009 > 4. Technical Description > > STREAMS and Character Device Coexistence > ---------------------------------------- > From Garrett.Damore@sun.com Mon Jul 6 15:09:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n66M9i79017771 for ; Mon, 6 Jul 2009 15:09:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n66M9hwi022953 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 6 Jul 2009 15:09:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMD00C09S86N300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 06 Jul 2009 16:09:42 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMD005F9S80FTE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 06 Jul 2009 16:09:36 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n66M9ZhF011457 for ; Mon, 06 Jul 2009 15:09:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMD00600S7V6R00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 06 Jul 2009 15:09:35 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMD00LG5S7YME20@fe-sfbay-09.sun.com>; Mon, 06 Jul 2009 15:09:34 -0700 (PDT) Date: Mon, 06 Jul 2009 15:09:34 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090706205843.GL993184@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A52761E.9020209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3868 Edward Pilatowicz wrote: > hey garrett, > some quick questions. > > - this new functionality seems to be tied to the vnode/specfs layer > which is how userland and the ldi accesses devices, so presumably this > streams to cb_ops fall back behaviour will be supported for both userland > and ldi based device access? (i assume so.) > That would certainly be my plan. > - will this fall back behaviour be supported for CLONE_DEV based minor > nodes? (i assume not.) > I think it would be. The only thing special about clone opens is that some minor number (typically 0 for NIC devices) is "special" and may not be associated with a physical instance. There isn't anything I can think of that would preclude this behavior. Granted, I would really, really like to see the need for CLONE_DEV devices go away. (I think this is largely a DLPI style 2 artifact. Everyone should DLPI style 1.) > - once a device minor node is successfully opened, the underlying driver > must have decided on streams or cb_ops based access. so: > > - if it decided on cb_ops accesses, will subsequent opens go > directly to the cb_ops open routine? (i assume so.) > Yes. > - if it decided on streams access, is it valid for subsequent > open calls to return ENOSTR? (i assume not.) > Subsequent open() calls with the same *minor* number cannot do that. However, subsequent opens with different minor numbers can do this. The selection is based on minor number. > - device open/close exclusion guarantees are implemented separately for > streams and cb_ops based access. presumably these guarantees will > still apply to devices that can switch between streams and cb_ops based > accesses? (in which case i guess the properties defined in > PSARC/2007/310 will be applicable to streams based drivers.) > Yes. Actually, the semantics described in 2007/310 are meaningful for *both* streams and character devices. > - do you anticipate having individual minor device nodes that switch > between cb_ops and steams based access? > No. A minor number is either STREAMS or cb_ops, but not both. The determination is made at open(2) time, which is effectively a "constructor". > - instead of having the streams open entry point return ENOSTR to fall > back to cb_ops, did you consider adding a new flag to > ddi_create_minor_node() so that a driver could specify the desired > access semantics of a given minor node? > I didn't think of that... I originally considered a dev_ops flag to trigger the dynamic behavior, but decided I didn't need one. I'd have to contemplate whether the minor node flag would even be workable... it probably is. What would the benefit be, though? > - what is the commitment level of this new ENOSTR interface? > Whoops, I forgot to specify that! I think Committed would be good, but if someone else wants a lower commitment, I'm OK with anything between Consolidation Private and Committed. :-) Most third party drivers that would want to make use of this behavior would probably need to resolve other Consolidation Private issues, so it may not make much difference. -- Garrett > ed > > On Mon, Jul 06, 2009 at 08:55:44AM -0700, Garrett D'Amore - sun microsystems wrote: > >> I'm submitting the following case on my own behalf. Times out on 7/13/2009. >> This case seeks patch binding. >> >> 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: >> STREAMS and Character Device Coexistence >> 1.2. Name of Document Author/Supplier: >> Author: Garrett D'Amore >> 1.3 Date of This Document: >> 06 July, 2009 >> 4. Technical Description >> >> STREAMS and Character Device Coexistence >> ---------------------------------------- >> >> From edward.pilatowicz@sun.com Tue Jul 7 17:09:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6809E4x006257 for ; Tue, 7 Jul 2009 17:09:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n68092un001396 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 08:09:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00307SFA7G00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 17:09:10 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF000WRSF9EP20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 17:09:09 -0700 (PDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n68099mY028261; Tue, 07 Jul 2009 17:09:09 -0700 (PDT) Date: Tue, 07 Jul 2009 17:09:08 -0700 From: Edward Pilatowicz Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A52761E.9020209@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20090708000908.GC716495@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 3304 On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: > Edward Pilatowicz wrote: >> hey garrett, >> some quick questions. >> >> - will this fall back behaviour be supported for CLONE_DEV based minor >> nodes? (i assume not.) >> > > I think it would be. The only thing special about clone opens is that > some minor number (typically 0 for NIC devices) is "special" and may not > be associated with a physical instance. There isn't anything I can think > of that would preclude this behavior. > > Granted, I would really, really like to see the need for CLONE_DEV > devices go away. (I think this is largely a DLPI style 2 artifact. > Everyone should DLPI style 1.) > really? i think that supporting this fall back behaviour for CLONE_DEV based minor nodes is a would introduce unnecessary complexity. putting aside the issue that we'd all like to see CLONE_DEV go away, the clone driver was never designed to work with non-streams devices. you'd probably have to modify it pretty extensively to support this fall back to cb_ops mode. either that or you'd have to add more clone dev device specific knowledge to spec_open(). also, CLONE_DEV open semantics wrt dev_t - dip bindings are very different from normal device opens. opens of CLONE_DEV minor nodes result in a dev_t that isn't bound to any dip. all non CLONE_DEV opens are required to be bound to a dip before the open can proceed. if you try to support fall back for these nodes it will be impossible to establish this binding before invoking the cb_ops open routine because you don't know what the cloned dev_t will be. so essentially you'd be introducing a new window where a driver open routine could be invoke on a minor node that is not actually bound to any device instance. >> - instead of having the streams open entry point return ENOSTR to fall >> back to cb_ops, did you consider adding a new flag to >> ddi_create_minor_node() so that a driver could specify the desired >> access semantics of a given minor node? >> > > I didn't think of that... I originally considered a dev_ops flag to > trigger the dynamic behavior, but decided I didn't need one. > > I'd have to contemplate whether the minor node flag would even be > workable... it probably is. What would the benefit be, though? > the benefit would be that you wouldn't have to open a device to know how it's going to behave. with the current semantics, until you open the device you don't know how it should be accessed. this could be used by consumers to help decide how they want to access a device. it could also be used by the framework to verify that a device is behaving as expected. (think more ASSERTs.) >> - what is the commitment level of this new ENOSTR interface? >> > > Whoops, I forgot to specify that! I think Committed would be good, but > if someone else wants a lower commitment, I'm OK with anything between > Consolidation Private and Committed. :-) > > Most third party drivers that would want to make use of this behavior > would probably need to resolve other Consolidation Private issues, so it > may not make much difference. > given that there aren't many drivers that will use this functionality, i'd personally prefer something like Consolidation Private. but perhaps i'm just being overly conservative. ed From Garrett.Damore@Sun.COM Tue Jul 7 18:00:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6810iqA006865 for ; Tue, 7 Jul 2009 18:00:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6810eJD013573 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 7 Jul 2009 18:00:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00803UT83G00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:00:44 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00BDFUT7MT70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:00:43 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6810hFA006620 for ; Tue, 07 Jul 2009 18:00:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMF00400UKUI700@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:00:43 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMF00AN6USZQ360@fe-sfbay-09.sun.com>; Tue, 07 Jul 2009 18:00:36 -0700 (PDT) Date: Tue, 07 Jul 2009 18:00:35 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090708000908.GC716495@eng.sun.com> Sender: Garrett.Damore@Sun.COM To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM Reply-to: Garrett.Damore@Sun.COM Message-id: <4A53EFB3.6040701@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4897 Edward Pilatowicz wrote: > On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: > >> Edward Pilatowicz wrote: >> >>> hey garrett, >>> some quick questions. >>> >>> - will this fall back behaviour be supported for CLONE_DEV based minor >>> nodes? (i assume not.) >>> >>> >> I think it would be. The only thing special about clone opens is that >> some minor number (typically 0 for NIC devices) is "special" and may not >> be associated with a physical instance. There isn't anything I can think >> of that would preclude this behavior. >> >> Granted, I would really, really like to see the need for CLONE_DEV >> devices go away. (I think this is largely a DLPI style 2 artifact. >> Everyone should DLPI style 1.) >> >> > > really? i think that supporting this fall back behaviour for CLONE_DEV > based minor nodes is a would introduce unnecessary complexity. > > putting aside the issue that we'd all like to see CLONE_DEV go away, the > clone driver was never designed to work with non-streams devices. you'd > probably have to modify it pretty extensively to support this fall back > to cb_ops mode. either that or you'd have to add more clone dev device > specific knowledge to spec_open(). > Why? Wouldn't a device driver just return ENOSTR just like any other? In order to be most useful, this feature has to be available to NIC devices, which make use of CLONE_DEV for DLPI style 2 (*cough*). I don't see why any interaction with the clone device driver is at all required. > also, CLONE_DEV open semantics wrt dev_t - dip bindings are very > different from normal device opens. opens of CLONE_DEV minor nodes > result in a dev_t that isn't bound to any dip. all non CLONE_DEV opens > are required to be bound to a dip before the open can proceed. if you > try to support fall back for these nodes it will be impossible to > establish this binding before invoking the cb_ops open routine because > you don't know what the cloned dev_t will be. so essentially you'd be > introducing a new window where a driver open routine could be invoke on > a minor node that is not actually bound to any device instance. > Yes, but the window is already there. Its a defect of CLONE_DEV. Either way you need a minor node to be out there, either via the clone device or via a "real" node. If a GLDv3 NIC driver creates a clone dev, then the minor node will still be available. Let me be clearer here: it will not be possible for the clone device driver to yield a reference to a non-STREAMS device node. But if a driver using the new semantics wants to export a CLONE_DEV node, there isn't a problem. It can also export regular nodes. No problem. > >>> - instead of having the streams open entry point return ENOSTR to fall >>> back to cb_ops, did you consider adding a new flag to >>> ddi_create_minor_node() so that a driver could specify the desired >>> access semantics of a given minor node? >>> >>> >> I didn't think of that... I originally considered a dev_ops flag to >> trigger the dynamic behavior, but decided I didn't need one. >> >> I'd have to contemplate whether the minor node flag would even be >> workable... it probably is. What would the benefit be, though? >> >> > > the benefit would be that you wouldn't have to open a device to know how > it's going to behave. with the current semantics, until you open the > device you don't know how it should be accessed. this could be used by > consumers to help decide how they want to access a device. it could > also be used by the framework to verify that a device is behaving as > expected. (think more ASSERTs.) > I see a lot of new code, and very little benefit gained. For nodes that export both STREAMS and character nodes, it would save an extra open() call. But apart from that, there is no tangible benefit. To see my sample implementation (which I've now tested with a modified version of my audio framework), see http://cr.opensolaris.org/~gdamore/schism/ Its only 18 lines of change, and yet it *works*. KISS. > >>> - what is the commitment level of this new ENOSTR interface? >>> >>> >> Whoops, I forgot to specify that! I think Committed would be good, but >> if someone else wants a lower commitment, I'm OK with anything between >> Consolidation Private and Committed. :-) >> >> Most third party drivers that would want to make use of this behavior >> would probably need to resolve other Consolidation Private issues, so it >> may not make much difference. >> >> > > given that there aren't many drivers that will use this functionality, > i'd personally prefer something like Consolidation Private. but perhaps > i'm just being overly conservative. > Sure whatever. I don't really care. Consolidation Private is enough for my own use. I was thinking of future 3rd party consumers. - Garrett > ed > From edward.pilatowicz@Sun.COM Tue Jul 7 18:49:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n681n6KF008141 for ; Tue, 7 Jul 2009 18:49:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n681n34C000099 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 7 Jul 2009 18:49:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00105X1T7H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:49:05 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00I28X1T0K20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:49:05 -0700 (PDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n681n4HU008242; Tue, 07 Jul 2009 18:49:04 -0700 (PDT) Date: Tue, 07 Jul 2009 18:49:03 -0700 From: Edward Pilatowicz Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A53EFB3.6040701@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM Message-id: <20090708014903.GE716495@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 5302 On Tue, Jul 07, 2009 at 06:00:35PM -0700, Garrett D'Amore wrote: > Edward Pilatowicz wrote: >> On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: >> >>> Edward Pilatowicz wrote: >>> >>>> hey garrett, >>>> some quick questions. >>>> >>>> - will this fall back behaviour be supported for CLONE_DEV based minor >>>> nodes? (i assume not.) >>>> >>>> >>> I think it would be. The only thing special about clone opens is that >>> some minor number (typically 0 for NIC devices) is "special" and may not >>> be associated with a physical instance. There isn't anything I can think >>> of that would preclude this behavior. >>> >>> Granted, I would really, really like to see the need for CLONE_DEV >>> devices go away. (I think this is largely a DLPI style 2 artifact. >>> Everyone should DLPI style 1.) >>> >>> >> >> really? i think that supporting this fall back behaviour for CLONE_DEV >> based minor nodes is a would introduce unnecessary complexity. >> >> putting aside the issue that we'd all like to see CLONE_DEV go away, the >> clone driver was never designed to work with non-streams devices. you'd >> probably have to modify it pretty extensively to support this fall back >> to cb_ops mode. either that or you'd have to add more clone dev device >> specific knowledge to spec_open(). >> > > Why? Wouldn't a device driver just return ENOSTR just like any other? > > In order to be most useful, this feature has to be available to NIC > devices, which make use of CLONE_DEV for DLPI style 2 (*cough*). I don't > see why any interaction with the clone device driver is at all required. > because during a CLONE_DEV open, spec_open() invokes the clone drivers streams open entry point. that in turn invokes the target drivers streams open entry point. if that returns ENOSTR, then the clone driver will pass that result back to spec_open(). so then with your changes spec_open() will attempt to invoke the clone drivers cb_ops open entry point, which doesn't exist. hence my comments that to support this you'll need to change the clone driver (to create a cb_ops open entry point for it) or you'll need to bake more clone driver specific knowledge into spec_open(). >> also, CLONE_DEV open semantics wrt dev_t - dip bindings are very >> different from normal device opens. opens of CLONE_DEV minor nodes >> result in a dev_t that isn't bound to any dip. all non CLONE_DEV opens >> are required to be bound to a dip before the open can proceed. if you >> try to support fall back for these nodes it will be impossible to >> establish this binding before invoking the cb_ops open routine because >> you don't know what the cloned dev_t will be. so essentially you'd be >> introducing a new window where a driver open routine could be invoke on >> a minor node that is not actually bound to any device instance. >> > > Yes, but the window is already there. Its a defect of CLONE_DEV. Either > way you need a minor node to be out there, either via the clone device > or via a "real" node. If a GLDv3 NIC driver creates a clone dev, then > the minor node will still be available. > > Let me be clearer here: it will not be possible for the clone device > driver to yield a reference to a non-STREAMS device node. But if a > driver using the new semantics wants to export a CLONE_DEV node, there > isn't a problem. It can also export regular nodes. No problem. ok. so it sounds like we're actually on the same page. the fallback behavior is NOT supported for CLONE_DEV based minor nodes. all CLONE_DEV based minor nodes MUST return a stream. (but the driver can feel free to create other non CLONE_DEV minor nodes which can function as non-stream nodes.) >> >>>> - instead of having the streams open entry point return ENOSTR to fall >>>> back to cb_ops, did you consider adding a new flag to >>>> ddi_create_minor_node() so that a driver could specify the desired >>>> access semantics of a given minor node? >>>> >>>> >>> I didn't think of that... I originally considered a dev_ops flag to >>> trigger the dynamic behavior, but decided I didn't need one. >>> >>> I'd have to contemplate whether the minor node flag would even be >>> workable... it probably is. What would the benefit be, though? >>> >>> >> >> the benefit would be that you wouldn't have to open a device to know how >> it's going to behave. with the current semantics, until you open the >> device you don't know how it should be accessed. this could be used by >> consumers to help decide how they want to access a device. it could >> also be used by the framework to verify that a device is behaving as >> expected. (think more ASSERTs.) >> > > I see a lot of new code, and very little benefit gained. For nodes that > export both STREAMS and character nodes, it would save an extra open() > call. But apart from that, there is no tangible benefit. > > To see my sample implementation (which I've now tested with a modified > version of my audio framework), see > > http://cr.opensolaris.org/~gdamore/schism/ > > Its only 18 lines of change, and yet it *works*. KISS. > yeah. i looked briefly at that. i noticed you didn't make any updates to the ldi. i expect you'll need to. you'll probably want to include test cases for accessing one of your fallback device nodes via the ldi. ed From Garrett.Damore@sun.com Tue Jul 7 18:57:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n681vnXQ008543 for ; Tue, 7 Jul 2009 18:57:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n681vkRO016639 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 02:57:48 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00E0FXGBQI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:57:47 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00BQAXGBMZ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:57:47 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n681vl8J009203 for ; Tue, 07 Jul 2009 18:57:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMF00B00X80CT00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:57:47 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMF00BE7XGAJS00@fe-sfbay-09.sun.com>; Tue, 07 Jul 2009 18:57:46 -0700 (PDT) Date: Tue, 07 Jul 2009 18:57:46 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090708014903.GE716495@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A53FD1A.50209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 6518 Edward Pilatowicz wrote: > On Tue, Jul 07, 2009 at 06:00:35PM -0700, Garrett D'Amore wrote: > >> Edward Pilatowicz wrote: >> >>> On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: >>> >>> >>>> Edward Pilatowicz wrote: >>>> >>>> >>>>> hey garrett, >>>>> some quick questions. >>>>> >>>>> - will this fall back behaviour be supported for CLONE_DEV based minor >>>>> nodes? (i assume not.) >>>>> >>>>> >>>>> >>>> I think it would be. The only thing special about clone opens is that >>>> some minor number (typically 0 for NIC devices) is "special" and may not >>>> be associated with a physical instance. There isn't anything I can think >>>> of that would preclude this behavior. >>>> >>>> Granted, I would really, really like to see the need for CLONE_DEV >>>> devices go away. (I think this is largely a DLPI style 2 artifact. >>>> Everyone should DLPI style 1.) >>>> >>>> >>>> >>> really? i think that supporting this fall back behaviour for CLONE_DEV >>> based minor nodes is a would introduce unnecessary complexity. >>> >>> putting aside the issue that we'd all like to see CLONE_DEV go away, the >>> clone driver was never designed to work with non-streams devices. you'd >>> probably have to modify it pretty extensively to support this fall back >>> to cb_ops mode. either that or you'd have to add more clone dev device >>> specific knowledge to spec_open(). >>> >>> >> Why? Wouldn't a device driver just return ENOSTR just like any other? >> >> In order to be most useful, this feature has to be available to NIC >> devices, which make use of CLONE_DEV for DLPI style 2 (*cough*). I don't >> see why any interaction with the clone device driver is at all required. >> >> > > because during a CLONE_DEV open, spec_open() invokes the clone drivers > streams open entry point. that in turn invokes the target drivers > streams open entry point. if that returns ENOSTR, then the clone driver > will pass that result back to spec_open(). so then with your changes > spec_open() will attempt to invoke the clone drivers cb_ops open entry > point, which doesn't exist. > That's actually OK. Because you'd never try a CLONE_DEV open unless you wanted STREAMS semantics. My point is that a device case can export a minor node that supports that CLONE_DEV minor node, and a minor node that doesn't. (In fact, all GLDv3 drivers do this... look at /dev/iprb vs. /dev/iprb0 (or pick your NIC driver) for an example. I just want to be able to add other kinds of minor nodes. > hence my comments that to support this you'll need to change the clone > driver (to create a cb_ops open entry point for it) or you'll need to > bake more clone driver specific knowledge into spec_open(). > I don't need to do either. I need not support a CLONE_DEV falling back to cb_ops. That would be nonsensical, IMO. Supporting mixing and matching of CLONE_DEV, STREAMS, and regular minor nodes in the same device instance *is* a goal, and that works even without changes to the clone dev or special knowledge in specfs. > >>> also, CLONE_DEV open semantics wrt dev_t - dip bindings are very >>> different from normal device opens. opens of CLONE_DEV minor nodes >>> result in a dev_t that isn't bound to any dip. all non CLONE_DEV opens >>> are required to be bound to a dip before the open can proceed. if you >>> try to support fall back for these nodes it will be impossible to >>> establish this binding before invoking the cb_ops open routine because >>> you don't know what the cloned dev_t will be. so essentially you'd be >>> introducing a new window where a driver open routine could be invoke on >>> a minor node that is not actually bound to any device instance. >>> >>> >> Yes, but the window is already there. Its a defect of CLONE_DEV. Either >> way you need a minor node to be out there, either via the clone device >> or via a "real" node. If a GLDv3 NIC driver creates a clone dev, then >> the minor node will still be available. >> >> Let me be clearer here: it will not be possible for the clone device >> driver to yield a reference to a non-STREAMS device node. But if a >> driver using the new semantics wants to export a CLONE_DEV node, there >> isn't a problem. It can also export regular nodes. No problem. >> > > ok. so it sounds like we're actually on the same page. the fallback > behavior is NOT supported for CLONE_DEV based minor nodes. all > CLONE_DEV based minor nodes MUST return a stream. (but the driver can > feel free to create other non CLONE_DEV minor nodes which can function > as non-stream nodes.) > *RIGHT*. Okay, yes, we're on the same page then. :-) > >>>>> - instead of having the streams open entry point return ENOSTR to fall >>>>> back to cb_ops, did you consider adding a new flag to >>>>> ddi_create_minor_node() so that a driver could specify the desired >>>>> access semantics of a given minor node? >>>>> >>>>> >>>>> >>>> I didn't think of that... I originally considered a dev_ops flag to >>>> trigger the dynamic behavior, but decided I didn't need one. >>>> >>>> I'd have to contemplate whether the minor node flag would even be >>>> workable... it probably is. What would the benefit be, though? >>>> >>>> >>>> >>> the benefit would be that you wouldn't have to open a device to know how >>> it's going to behave. with the current semantics, until you open the >>> device you don't know how it should be accessed. this could be used by >>> consumers to help decide how they want to access a device. it could >>> also be used by the framework to verify that a device is behaving as >>> expected. (think more ASSERTs.) >>> >>> >> I see a lot of new code, and very little benefit gained. For nodes that >> export both STREAMS and character nodes, it would save an extra open() >> call. But apart from that, there is no tangible benefit. >> >> To see my sample implementation (which I've now tested with a modified >> version of my audio framework), see >> >> http://cr.opensolaris.org/~gdamore/schism/ >> >> Its only 18 lines of change, and yet it *works*. KISS. >> >> > > yeah. i looked briefly at that. i noticed you didn't make any updates > to the ldi. i expect you'll need to. you'll probably want to include > test cases for accessing one of your fallback device nodes via the ldi. > Good point... I'll have a look see. I'd have thought ldi would go thru specfs. Does it not? - Garrett > ed > From Garrett.Damore@sun.com Tue Jul 7 18:59:15 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n681xE3W008564 for ; Tue, 7 Jul 2009 18:59:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n681xAip017382 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 02:59:14 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00A05XIPCJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:59:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00LNDXIOYD90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:59:12 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n681xC87009260 for ; Tue, 07 Jul 2009 18:59:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMF00000XEV9W00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 18:59:12 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMF00AZVXINK940@fe-sfbay-10.sun.com>; Tue, 07 Jul 2009 18:59:12 -0700 (PDT) Date: Tue, 07 Jul 2009 18:59:11 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090708014903.GE716495@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A53FD6F.6000502@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 514 Edward Pilatowicz wrote: >> >> http://cr.opensolaris.org/~gdamore/schism/ >> >> Its only 18 lines of change, and yet it *works*. KISS. >> >> > > yeah. i looked briefly at that. i noticed you didn't make any updates > to the ldi. i expect you'll need to. you'll probably want to include > test cases for accessing one of your fallback device nodes via the ldi. > > ed > Ah ha! I do need to change it. Its another STREAMSTAB() check that needs to be converted into a check for vp->v_stream. - Garrett From edward.pilatowicz@sun.com Tue Jul 7 19:39:31 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n682dUcw008873 for ; Tue, 7 Jul 2009 19:39:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n682dOoL018292 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 10:39:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF00B03ZDRXW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:39:27 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00INTZDQ0F50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 19:39:26 -0700 (PDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n682dQdU031056; Tue, 07 Jul 2009 19:39:26 -0700 (PDT) Date: Tue, 07 Jul 2009 19:39:26 -0700 From: Edward Pilatowicz Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A53FD1A.50209@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20090708023925.GA748578@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2167 On Tue, Jul 07, 2009 at 06:57:46PM -0700, Garrett D'Amore wrote: > Edward Pilatowicz wrote: >> On Tue, Jul 07, 2009 at 06:00:35PM -0700, Garrett D'Amore wrote: >>> Edward Pilatowicz wrote: >>>> On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: >>>>> Edward Pilatowicz wrote: >>>>>> - instead of having the streams open entry point return ENOSTR to fall >>>>>> back to cb_ops, did you consider adding a new flag to >>>>>> ddi_create_minor_node() so that a driver could specify the desired >>>>>> access semantics of a given minor node? >>>>>> >>>>> I didn't think of that... I originally considered a dev_ops flag to >>>>> trigger the dynamic behavior, but decided I didn't need one. >>>>> >>>>> I'd have to contemplate whether the minor node flag would even be >>>>> workable... it probably is. What would the benefit be, though? >>>>> >>>> the benefit would be that you wouldn't have to open a device to know how >>>> it's going to behave. with the current semantics, until you open the >>>> device you don't know how it should be accessed. this could be used by >>>> consumers to help decide how they want to access a device. it could >>>> also be used by the framework to verify that a device is behaving as >>>> expected. (think more ASSERTs.) >>>> >>> I see a lot of new code, and very little benefit gained. For nodes that >>> export both STREAMS and character nodes, it would save an extra open() >>> call. But apart from that, there is no tangible benefit. >>> >>> To see my sample implementation (which I've now tested with a modified >>> version of my audio framework), see >>> >>> http://cr.opensolaris.org/~gdamore/schism/ >>> >>> Its only 18 lines of change, and yet it *works*. KISS. >>> >> >> yeah. i looked briefly at that. i noticed you didn't make any updates >> to the ldi. i expect you'll need to. you'll probably want to include >> test cases for accessing one of your fallback device nodes via the ldi. >> > > Good point... I'll have a look see. I'd have thought ldi would go thru > specfs. Does it not? > the ldi does go through specfs, but not all streams operations go through specfs (think putmsg, getmsg). ed From Garrett.Damore@sun.com Wed Jul 8 09:06:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n68G6ohV003152 for ; Wed, 8 Jul 2009 09:06:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n68G6jiw041442 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 10:06:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMH00L090RBT400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 09:06:47 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00E7C0RBW4C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 09:06:47 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n68G6kYE022584 for ; Wed, 08 Jul 2009 09:06:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00C000M2HT00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 09:06:46 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH009GJ0RAPQ90@fe-sfbay-09.sun.com>; Wed, 08 Jul 2009 09:06:46 -0700 (PDT) Date: Wed, 08 Jul 2009 09:06:46 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090708023925.GA748578@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A54C416.8090902@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 63 Btw, I'm still looking for a plus one on this case. - Garrett From Garrett.Damore@sun.com Wed Jul 8 18:42:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n691glvM029083 for ; Wed, 8 Jul 2009 18:42:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n691ghHt023011 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 09:42:46 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMH00C01RF9R800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 19:42:45 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00519RF9L6F0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 19:42:45 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n691giXJ019993 for ; Wed, 08 Jul 2009 18:42:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00M00RDIS600@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 18:42:44 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH000RORF8KU70@fe-sfbay-10.sun.com>; Wed, 08 Jul 2009 18:42:44 -0700 (PDT) Date: Wed, 08 Jul 2009 18:42:44 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090708023925.GA748578@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A554B14.60700@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3021 For the case record, I've fixed this so that the code works with LDI (verified with a special kernel test module). I've also tried to make sure it will support block devices equally well, though I don't have any block devices to test it with. The webrev for interested parties is here: http://cr.opensolaris.org/~gdamore/schism/ (For a while anyway... I expect this case log will probably outlive the webrev, but by then there should be history in Hg for this case number... assuming that the case is approved as I hope it will be.) Still looking for another member to +1 it, btw. -- Garrett Edward Pilatowicz wrote: > On Tue, Jul 07, 2009 at 06:57:46PM -0700, Garrett D'Amore wrote: > >> Edward Pilatowicz wrote: >> >>> On Tue, Jul 07, 2009 at 06:00:35PM -0700, Garrett D'Amore wrote: >>> >>>> Edward Pilatowicz wrote: >>>> >>>>> On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: >>>>> >>>>>> Edward Pilatowicz wrote: >>>>>> >>>>>>> - instead of having the streams open entry point return ENOSTR to fall >>>>>>> back to cb_ops, did you consider adding a new flag to >>>>>>> ddi_create_minor_node() so that a driver could specify the desired >>>>>>> access semantics of a given minor node? >>>>>>> >>>>>>> >>>>>> I didn't think of that... I originally considered a dev_ops flag to >>>>>> trigger the dynamic behavior, but decided I didn't need one. >>>>>> >>>>>> I'd have to contemplate whether the minor node flag would even be >>>>>> workable... it probably is. What would the benefit be, though? >>>>>> >>>>>> >>>>> the benefit would be that you wouldn't have to open a device to know how >>>>> it's going to behave. with the current semantics, until you open the >>>>> device you don't know how it should be accessed. this could be used by >>>>> consumers to help decide how they want to access a device. it could >>>>> also be used by the framework to verify that a device is behaving as >>>>> expected. (think more ASSERTs.) >>>>> >>>>> >>>> I see a lot of new code, and very little benefit gained. For nodes that >>>> export both STREAMS and character nodes, it would save an extra open() >>>> call. But apart from that, there is no tangible benefit. >>>> >>>> To see my sample implementation (which I've now tested with a modified >>>> version of my audio framework), see >>>> >>>> http://cr.opensolaris.org/~gdamore/schism/ >>>> >>>> Its only 18 lines of change, and yet it *works*. KISS. >>>> >>>> >>> yeah. i looked briefly at that. i noticed you didn't make any updates >>> to the ldi. i expect you'll need to. you'll probably want to include >>> test cases for accessing one of your fallback device nodes via the ldi. >>> >>> >> Good point... I'll have a look see. I'd have thought ldi would go thru >> specfs. Does it not? >> >> > > the ldi does go through specfs, but not all streams operations go > through specfs (think putmsg, getmsg). > > ed > From edward.pilatowicz@sun.com Wed Jul 8 19:46:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n692kcLG000692 for ; Wed, 8 Jul 2009 19:46:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n692kWTi002820 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 03:46:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMH00107UDPT900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 19:46:37 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00JRJUDPKL90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 19:46:37 -0700 (PDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n692kWQm040348; Wed, 08 Jul 2009 19:46:32 -0700 (PDT) Date: Wed, 08 Jul 2009 19:46:32 -0700 From: Edward Pilatowicz Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A554B14.60700@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20090709024631.GC202488@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> <4A554B14.60700@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 3166 fyi, i'm not a psarc member. i'm just a heckler[1]. ed 1 - http://en.wikipedia.org/wiki/Statler_&_Waldorf On Wed, Jul 08, 2009 at 06:42:44PM -0700, Garrett D'Amore wrote: > For the case record, I've fixed this so that the code works with LDI > (verified with a special kernel test module). I've also tried to make > sure it will support block devices equally well, though I don't have any > block devices to test it with. > > The webrev for interested parties is here: > > http://cr.opensolaris.org/~gdamore/schism/ > > (For a while anyway... I expect this case log will probably outlive the > webrev, but by then there should be history in Hg for this case > number... assuming that the case is approved as I hope it will be.) > > Still looking for another member to +1 it, btw. > > -- Garrett > > Edward Pilatowicz wrote: >> On Tue, Jul 07, 2009 at 06:57:46PM -0700, Garrett D'Amore wrote: >> >>> Edward Pilatowicz wrote: >>> >>>> On Tue, Jul 07, 2009 at 06:00:35PM -0700, Garrett D'Amore wrote: >>>> >>>>> Edward Pilatowicz wrote: >>>>> >>>>>> On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: >>>>>> >>>>>>> Edward Pilatowicz wrote: >>>>>>> >>>>>>>> - instead of having the streams open entry point return ENOSTR to fall >>>>>>>> back to cb_ops, did you consider adding a new flag to >>>>>>>> ddi_create_minor_node() so that a driver could specify the desired >>>>>>>> access semantics of a given minor node? >>>>>>>> >>>>>>>> >>>>>>> I didn't think of that... I originally considered a dev_ops flag to >>>>>>> trigger the dynamic behavior, but decided I didn't need one. >>>>>>> >>>>>>> I'd have to contemplate whether the minor node flag would even be >>>>>>> workable... it probably is. What would the benefit be, though? >>>>>>> >>>>>>> >>>>>> the benefit would be that you wouldn't have to open a device to know how >>>>>> it's going to behave. with the current semantics, until you open the >>>>>> device you don't know how it should be accessed. this could be used by >>>>>> consumers to help decide how they want to access a device. it could >>>>>> also be used by the framework to verify that a device is behaving as >>>>>> expected. (think more ASSERTs.) >>>>>> >>>>>> >>>>> I see a lot of new code, and very little benefit gained. For nodes that >>>>> export both STREAMS and character nodes, it would save an extra open() >>>>> call. But apart from that, there is no tangible benefit. >>>>> >>>>> To see my sample implementation (which I've now tested with a modified >>>>> version of my audio framework), see >>>>> >>>>> http://cr.opensolaris.org/~gdamore/schism/ >>>>> >>>>> Its only 18 lines of change, and yet it *works*. KISS. >>>>> >>>>> >>>> yeah. i looked briefly at that. i noticed you didn't make any updates >>>> to the ldi. i expect you'll need to. you'll probably want to include >>>> test cases for accessing one of your fallback device nodes via the ldi. >>>> >>>> >>> Good point... I'll have a look see. I'd have thought ldi would go thru >>> specfs. Does it not? >>> >>> >> >> the ldi does go through specfs, but not all streams operations go >> through specfs (think putmsg, getmsg). >> >> ed >> From carlsonj@workingcode.com Wed Jul 8 20:31:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n693VE5s003925 for ; Wed, 8 Jul 2009 20:31:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n693UmGY018718; Thu, 9 Jul 2009 11:31:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMH00L01WFWNT00@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 20:31:08 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00CODWFVAY60@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 20:31:07 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n693V7Fn004318; Thu, 09 Jul 2009 03:31:07 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-4145664; Thu, 09 Jul 2009 03:29:07 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-171481812; Thu, 09 Jul 2009 03:29:06 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-14164049; Thu, 09 Jul 2009 03:29:06 +0000 (Z) Received: from dhcp-160.workingcode.com (dhcp-160 [192.168.254.160]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n693Ss54016772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 08 Jul 2009 23:28:55 -0400 (EDT) Date: Wed, 08 Jul 2009 23:28:29 -0400 From: James Carlson Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <20090709024631.GC202488@eng.sun.com> To: Edward Pilatowicz Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4A5563DD.6000505@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=3 Fuz1=3 X-Antispam: No, score=0.0/5.0, scanned in 0.192sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> <4A554B14.60700@sun.com> <20090709024631.GC202488@eng.sun.com> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 117 Edward Pilatowicz wrote: > fyi, i'm not a psarc member. > i'm just a heckler[1]. ARC review: hecklers wanted. ;-} From Garrett.Damore@Sun.COM Wed Jul 8 20:41:25 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n693fPUZ003962 for ; Wed, 8 Jul 2009 20:41:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n693fPwm002891 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 20:41:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMH00D05WX05Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 20:41:24 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00JKGWWYKLE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 20:41:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n693fGh2024939 for ; Wed, 08 Jul 2009 20:41:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00I00WR6SU00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 20:41:18 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH00KWYWVUPF80@fe-sfbay-10.sun.com>; Wed, 08 Jul 2009 20:40:43 -0700 (PDT) Date: Wed, 08 Jul 2009 20:40:42 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A5563DD.6000505@workingcode.com> Sender: Garrett.Damore@Sun.COM To: James Carlson Cc: Edward Pilatowicz , PSARC-ext@Sun.COM Reply-to: Garrett.Damore@Sun.COM Message-id: <4A5566BA.403@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> <4A554B14.60700@sun.com> <20090709024631.GC202488@eng.sun.com> <4A5563DD.6000505@workingcode.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 224 James Carlson wrote: > Edward Pilatowicz wrote: >> fyi, i'm not a psarc member. >> i'm just a heckler[1]. > > ARC review: hecklers wanted. > > ;-} > Another fair question: why aren't you a PSARC member? :-) - Garrett From Sebastien.Roy@Sun.COM Thu Jul 9 09:02:28 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n69G2Sja025170 for ; Thu, 9 Jul 2009 09:02:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n69G2O4G018795 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 09:02:27 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMI0013ZV83PI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 09:02:27 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMI00GXFV82BJC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 09:02:26 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n69G2QVD006847 for ; Thu, 09 Jul 2009 16:02:26 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMI00200U1OSZ00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 10:02:26 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMI00DCTV7Y2QA0@mail-amer.sun.com>; Thu, 09 Jul 2009 10:02:22 -0600 (MDT) Date: Thu, 09 Jul 2009 12:00:59 -0400 From: Sebastien Roy Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <200907061555.n66FtigT004861@sac.sfbay.sun.com> Sender: Sebastien.Roy@Sun.COM To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@Sun.COM, Garrett.Damore@Sun.COM Message-id: <1247155259.12038.136.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.1.1 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> Status: RO Content-Length: 201 On Mon, 2009-07-06 at 08:55 -0700, Garrett D'Amore - sun microsystems wrote: > I'm submitting the following case on my own behalf. Times out on 7/13/2009. > This case seeks patch binding. +1 -Seb From Garrett.Damore@sun.com Thu Jul 9 10:11:46 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n69HBjrF027304 for ; Thu, 9 Jul 2009 10:11:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n69HBNxQ010138 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 18:11:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMI0060JYFI3400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 10:11:42 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMI005HNYFHE010@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 10:11:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n69HBfJ8000460 for ; Thu, 09 Jul 2009 10:11:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMI00M00XI88800@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 09 Jul 2009 10:11:41 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMI00FBXYFCKKG0@fe-sfbay-09.sun.com>; Thu, 09 Jul 2009 10:11:36 -0700 (PDT) Date: Thu, 09 Jul 2009 10:11:36 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <1247155259.12038.136.camel@strat> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4A5624C8.2050209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <1247155259.12038.136.camel@strat> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 275 Sebastien Roy wrote: > On Mon, 2009-07-06 at 08:55 -0700, Garrett D'Amore - sun microsystems > wrote: > >> I'm submitting the following case on my own behalf. Times out on 7/13/2009. >> This case seeks patch binding. >> > > +1 > -Seb > > > Thanks. - Garrett From bart.smaalders@sun.com Thu Jul 9 10:26:29 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n69HQScp027417 for ; Thu, 9 Jul 2009 10:26:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n69HQJlT001914; Fri, 10 Jul 2009 01:26:24 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMI0040DZ3ZMZ00@brm-avmta-1.central.sun.com>; Thu, 09 Jul 2009 11:26:23 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMI00JL6Z3Y8G80@brm-avmta-1.central.sun.com>; Thu, 09 Jul 2009 11:26:22 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n69HPsio013604; Thu, 09 Jul 2009 17:25:54 +0000 (GMT) Date: Thu, 09 Jul 2009 10:18:48 -0700 From: Bart Smaalders Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A5566BA.403@sun.com> To: Garrett.Damore@sun.com Cc: James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <4A562678.9090205@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> <4A554B14.60700@sun.com> <20090709024631.GC202488@eng.sun.com> <4A5563DD.6000505@workingcode.com> <4A5566BA.403@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 1029 Garrett D'Amore wrote: > James Carlson wrote: >> Edward Pilatowicz wrote: >>> fyi, i'm not a psarc member. >>> i'm just a heckler[1]. >> >> ARC review: hecklers wanted. >> >> ;-} >> > Another fair question: why aren't you a PSARC member? :-) > > - Garrett > Because as a heckler, you get to chime in on the cases you care about, and yet not end up writing opinions, or trying to come up to speed on things far outside your areas of interest; this also helps keep one's time commitment to a more reasonable level. One of the problems that PSARC has had is that those who are doing interesting work often found it difficult to justify the time commitment involved in active participation. This would sometimes lead to having folks involved on PSARC who hadn't actually delivered a project involving substantial change to the system in many years. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Garrett.Damore@Sun.COM Thu Jul 9 10:55:20 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n69HtKdJ028360 for ; Thu, 9 Jul 2009 10:55:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n69HtKGq020758 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 10:55:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMJ00J010G8UJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 10:55:20 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMJ00FZ60G5TFD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 10:55:19 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n69HtHu4014476 for ; Thu, 09 Jul 2009 10:55:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMJ00A00092D100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 10:55:17 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMJ00EBP0G1YR00@fe-sfbay-09.sun.com>; Thu, 09 Jul 2009 10:55:13 -0700 (PDT) Date: Thu, 09 Jul 2009 10:55:13 -0700 From: "Garrett D'Amore" Subject: Re: STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009] In-reply-to: <4A562678.9090205@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Bart Smaalders Cc: James Carlson , Edward Pilatowicz , PSARC-ext@Sun.COM Reply-to: Garrett.Damore@Sun.COM Message-id: <4A562F01.5060106@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907061555.n66FtigT004861@sac.sfbay.sun.com> <20090706205843.GL993184@eng.sun.com> <4A52761E.9020209@sun.com> <20090708000908.GC716495@eng.sun.com> <4A53EFB3.6040701@sun.com> <20090708014903.GE716495@eng.sun.com> <4A53FD1A.50209@sun.com> <20090708023925.GA748578@eng.sun.com> <4A554B14.60700@sun.com> <20090709024631.GC202488@eng.sun.com> <4A5563DD.6000505@workingcode.com> <4A5566BA.403@sun.com> <4A562678.9090205@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1264 Bart Smaalders wrote: > Garrett D'Amore wrote: >> James Carlson wrote: >>> Edward Pilatowicz wrote: >>>> fyi, i'm not a psarc member. >>>> i'm just a heckler[1]. >>> >>> ARC review: hecklers wanted. >>> >>> ;-} >>> >> Another fair question: why aren't you a PSARC member? :-) >> >> - Garrett >> > > Because as a heckler, you get to chime in on the cases you care about, > and yet not end up writing opinions, or trying to come up to speed > on things far outside your areas of interest; this also helps keep > one's time commitment to a more reasonable level. > > One of the problems that PSARC has had is that those who are doing > interesting work often found it difficult to justify the time > commitment involved in active participation. This would sometimes > lead to having folks involved on PSARC who hadn't actually delivered > a project involving substantial change to the system in many years. This is what "Sabbatical" is for. :-) I'd like to think that I'm still highly active as an actual contributor, and am not burning huge amounts of my time on PSARC. (That said, PSARC *does* impose a non-trivial time commitment. But I believe that the end result is a net gain, both for myself and for the company...) - Garrett > > - Bart > > From Garrett.Damore@sun.com Mon Jul 13 17:32:24 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6E0WN8Q017401 for ; Mon, 13 Jul 2009 17:32:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6E0WNEd032755 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 13 Jul 2009 18:32:23 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMQ00303XHZ7D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 17:32:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMQ00KFFXHYMM90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 17:32:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6E0WMWQ028984 for ; Mon, 13 Jul 2009 17:32:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMQ00L00XGQYQ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 17:32:22 -0700 (PDT) Received: from [129.158.18.174] ([unknown] [129.158.18.174]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMQ00E9KXHVF0A0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 17:32:22 -0700 (PDT) Date: Mon, 13 Jul 2009 17:32:17 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/380 STREAMS and Character Device coexistence Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <4A5BD211.40403@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 158 As this case has converged, timed out, has a +1, and no -1's or requests to derail or for more time, I'm marking it closed approved. Thanks. - Garrett