Garrett D'Amore wrote: >> Probably better is to key the configuration off of the /dev name, >> which hides that lower-level stuff. > > Well, I'd settle for driver name and instance number. This is probably, > in some respects, simpler than /dev names, which can vary for different > kinds of devices (and some drivers might not even have a node in /dev!)
In some ways, yes, but OTOH it's not as directly human-understandable. Not that any of the device identifiers are very good for humans. The best answers are based on some of the almost-never-implemented "connector" identifiers, which would in theory let the platform and the device say things like "the orange connector on the card with the 'B' printed underneath it"... but only the platform and the device can supply that kind of information, and they probably don't, so you've got a chicken-and-egg problem. Also, there is an excellent argument that the driver name is an implementation detail and that it is the /dev name that is the appropriate abstraction. Should the identifier for a particular physical device change just because you changed which chunk of software is driving it? (Yeah, I know it *does* change for many or most devices, but is that a bug or a feature?) >> Why isn't the right answer to run an application that reads config >> files (or reads SMF properties) and issues ioctls to get the data into >> the driver? > > Well, we can do that, but the problem is making sure that the above > operation is done at the appropriate time. I need to have those values, > in some cases, at driver attach() time. By the time an application > comes around to populate it, it may be too late. I can believe that's true for some devices, but not many. Changing it might require a driver redesign so that the device is relatively inert until the config application runs, but such a redesign should be on the table. (I mean, if we're going to design something, maybe the right thing to design is the driver.) Can you offer a concrete example?
