On Tue, Dec 11, 2007 at 11:00:46PM -0800, Garrett D'Amore wrote: > Artem Kachitchkine wrote: > > > >> Heh. That's a nice theory. Except for one "itsy bitsy little > >> issue". Except for drivers for a few well known classes, you > >> *cannot* adhere to the DDI simply because there is no DDI compliant > >> way to populate /dev! The devfsadm plugin framework is clearly not > >> public (and its entirely > >> unsuited to being so right now... > > > > "It is true that managing of the /dev namespace could be made easier > > (esp. for leaf driver developers). I believe the issue is well > > recognized among the I/O framework folks, however the work started by > > the devname project is affected by lack of resources." :) > > > > The advantage is that when/if someone needs to change devfs, they > > would only need to look in "well known" places like devfsadm and > > libdevinfo, and not chase consumers all around the place (they would > > have to anyway, but minimizing the number of such places is everyone's > > job). > > Maybe its time to just bite the bullet and raise the commitment level of > /devices? I'd think that would be a lot easier. :-) I don't know what > the fear behind this is, that kept the devfs team from committing to it > already, but I can assure that the number of unbundled (and in some > cases non-Sun!) bits of software that rely on /devices is non-trivial. > For a number of us, /devices is also hardcoded into our human brains. > Changing the way /devices works would be akin to the change involving > SMF.... a lot of pain, and probably a need to retain backwards > compatibility. >
um. no. /devices should not be public. /dev is the way to go. if we put resources behind anything it should be coming up with public ways to manage and populate /dev. ed
