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 >> ---------------------------------------- >> >>
