Re: [PATCH] integrate driverfs and devfs (2.5.28)

[Adam Belay]

The problem is that a device without a mapping to a driver is a valid
> state.

Ok here's a new less devfs dependent idea.  Its sole goal is to 
acomplish the above.  Why not add a list to device like I did before 
only instead of using devfs handles to discover major and minor numbers 
I can store the major and minor numbers directly.  I could even use 
kdev_t.  This way it is not dependent on devfs and does not enforce any 
of its policies.  Then I'll create a quick interface for driverfs as 
well as a simple register and unregister function.  I'll name it dev 
like before and it can display information in the following format: 
 MAJOR, MINOR.  It will print one line per dev.  Finally I can use one 
of devfs's find functions to generate the path although I may just 
forget devfs entirely.  This interface is necessary because user level 
programs can determine which driverfs entries correspond to which 
entries in their dev directory.  I think this will be useful for hotplug 
as well as some of my own projects.  If you support this I'll get to 
work on a patch.  Also I had a driver model related question.  Should a 
driver be able to belong to more than one bus?  Also are you going to 
create an interface that exports drivers directly instead of only 
through bus and device class?
Thanks,
Adam