On Thu, Apr 23, 2009 at 08:01:42AM -0700, Garrett D'Amore wrote: > Darren Reed wrote: >> Garrett D'Amore wrote: >>> Darren Reed wrote: >>>> Garrett D'Amore wrote: >>>>> I think this proposal is well intentioned, but from my previous >>>>> experience in trying to "manage" minor number spaces in portable >>>>> frameworks, its hard to get this right. >>>> >>>> From your previous experience, do you think that it is worth >>>> spending time and effort trying to get it right? Or is what we have >>>> now "enough"? With some developer effort it works, but it doesn't >>>> really feel like that it was designed to be used that way? >>> >>> I'm not sure. Its a close call. >> .... >>>>> (And you might need different state structures for different >>>>> kinds of clone opens -- e.g. OSS has very different state than >>>>> the legacy Sun Audio.) >>>> >>>> I think this is less of a problem - the only state that can be >>>> passed into an entry point other than open is what was set during >>>> open and it is up to the driver to decide what to use. >>>> >>>> So now I expect a driver's ioctl routine would know where to get >>>> the pointer for the context based on the dev_t, whereas with what >>>> I'm suggesting, the driver needs to know how to use dev_t to >>>> convert the void* into the right pointer type. >>> >>> Yes. The problem is that there is not a good rule for mapping this >>> state... and without some knowledge of how minor numbers are used, it >>> becomes "difficult" to develop a general solution. >> >> In reflecting on your comments, I think the best that I could offer >> here would be to introduce a new flag that said the Solaris kernel was >> going to manage minor device number allocation and that each open(9e) >> call would get a unique minor number. >> >> That would provide 2 scenarious: when the flag is set, kernel manages >> all minor numbers and when it isn't set (like now), the driver is >> responsible. >> >> To try and have extra functions to allocate a minor number from a >> given number space seems to start down a path of diminishing returns >> when compared to the effort required to support it. > > Very few devices would be able to support this. > > The reason is that you have to separate the minor numbers *at least* > into non-cloneable and cloneable spaces... the driver needs to know what > the "original" minor number (not the cloned number) is so that it can > associated it with a specific instance. > > For pseudo drivers where you have only one instance maybe this isn't > necessary (although it means your driver can never have more than one > "type" of minor node). For all other hardware drivers, you need to know > the instance number. > > There's a reason that this hasn't been generalized before -- really. :-) > > Being able to pass "state" with a minor number would be somewhat useful. > But having automatic minor number allocation is almost completely useless > unless you have some control over the pool of numbers allocated from, and > access to the "original" minor node that the device opened (before the > new clone number was created.) >
so i've been watching the conversation and i haven't chimed in since my views pretty much align with garrett's. if you want to see a simple driver that uses id_alloc() and friends to manage it's minor number space, check out lx_audio.c. the usage is pretty strait forward. so while i don't see the minor number management interfaces as usefull, i do see the state handle as potentially usefull. i actually created such a handle in an old prototype i did for stacked drivers many years ago. in that case, use of the handle was controlled by a cb_ops device flag. there was a one-to-one mapping between the handle and a given minor node, and every driver in the stack had it's own handle. the data handles were stored in the common snode, and as long as all data access was done via the filesystem or the ldi (and not directly via driver.c interfaces), we would have access to the common snode to easily get the handles. this would save the driver from having to do any kind of lookups internally. ed _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
