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
