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