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 >
