Edward Pilatowicz wrote: > On Mon, Jul 06, 2009 at 03:09:34PM -0700, Garrett D'Amore wrote: > >> Edward Pilatowicz wrote: >> >>> hey garrett, >>> some quick questions. >>> >>> - 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.) >> >> > > really? i think that supporting this fall back behaviour for CLONE_DEV > based minor nodes is a would introduce unnecessary complexity. > > putting aside the issue that we'd all like to see CLONE_DEV go away, the > clone driver was never designed to work with non-streams devices. you'd > probably have to modify it pretty extensively to support this fall back > to cb_ops mode. either that or you'd have to add more clone dev device > specific knowledge to spec_open(). >
Why? Wouldn't a device driver just return ENOSTR just like any other? In order to be most useful, this feature has to be available to NIC devices, which make use of CLONE_DEV for DLPI style 2 (*cough*). I don't see why any interaction with the clone device driver is at all required. > also, CLONE_DEV open semantics wrt dev_t - dip bindings are very > different from normal device opens. opens of CLONE_DEV minor nodes > result in a dev_t that isn't bound to any dip. all non CLONE_DEV opens > are required to be bound to a dip before the open can proceed. if you > try to support fall back for these nodes it will be impossible to > establish this binding before invoking the cb_ops open routine because > you don't know what the cloned dev_t will be. so essentially you'd be > introducing a new window where a driver open routine could be invoke on > a minor node that is not actually bound to any device instance. > Yes, but the window is already there. Its a defect of CLONE_DEV. Either way you need a minor node to be out there, either via the clone device or via a "real" node. If a GLDv3 NIC driver creates a clone dev, then the minor node will still be available. Let me be clearer here: it will not be possible for the clone device driver to yield a reference to a non-STREAMS device node. But if a driver using the new semantics wants to export a CLONE_DEV node, there isn't a problem. It can also export regular nodes. No problem. > >>> - 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. > >>> - 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. >> >> > > given that there aren't many drivers that will use this functionality, > i'd personally prefer something like Consolidation Private. but perhaps > i'm just being overly conservative. > Sure whatever. I don't really care. Consolidation Private is enough for my own use. I was thinking of future 3rd party consumers. - Garrett > ed >
