PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory

[Garrett D'Amore]

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.

    -- Garrett