STREAMS and Character Device Coexistence [PSARC/2009/380 FastTrack timeout 07/13/2009]

[Garrett D'Amore]

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