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

[Garrett D'Amore]

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
>