> > > With devfs it could be a collection of links from
> > > filenames to /devfs/* entries.
> > By whom/how are permissions handled? Even if it's symlinks, the original
> > files in /devfs have to carry them (you can't follow symplinks to files you
> > can't access directly!). And that means the kernel has to know how to set
> > up permissions for a new device when it appears, and remember the settings
> > from one boot to the next. Gross. And a kludged initscript that sets them
> > up on each boot is even worse. As bad as the much-maligned MAKEDEV, but run
> > _each_ boot, so much more critical.
> I would like a devfs mounted on /dev which does nothing except report node
> accesses that ENODEV to devfsd.
kmod + modprobe are doing fine, thanks.
> Then devfsd can implement all the policies
> and naming schemes. Permissions can be handled with /etc/devfs.conf (which
> I think is neater than chmod in an ext2 based /dev anyway). The devfsd can
> be responsible for node creation with mknod(). Module insert/remove events
> can also report to devfsd, preferably with major/minor numbers, so that we
> could shove even more policy in devfsd. So perhaps a devfs.conf like
BTW, what do I access to get at the ZIP drive (i.e., today /dev/sda4 on my
machine)? It can't be /dev/sda4 if that piece of naming is done by devfsd,
which might decide today it's /dev/scsi/ppa/0/4... which obviously doesn't
exist until I tell the kernel to go looking for it? OK, I could look it up
in a magic place in /proc... but if I don't want to mount proc (perhaps for
security reasons, or whatever)? Anyway, now I'm dependent on a magic file
in /proc (with _that_ specific format!) that does not exist anywhere else
(bye, bye portability) _and_ /dev, and perhaps more stuff. Also, the above
might give rise to races.
And "Need Zip drive... OK, look how it should be called today...(root
around in /proc)... OK, it's called /dev/foo today, go access /dev/foo so
the kernel goes looking for it... nope, not found" sounds harder on the
user than "Look for /dev/zip (or whatever it is called _always_ in /dev),
if not found give up". Many programs will just go /dev/foo, and introduce
subtle bugs.
[...]
> This makes sense to me, and I think moves all policy that Tso and HPA have
> been unhappy about completely into a userspace devfsd. I also think it has
> the least impact on the existing functionality of devfs (you lose creation
> of nodes which don't have devfs.conf entries which might upset proprietary
> module developers, but that's about it). It also doesn't meet the proposal
> by Tso of providing bus/lun/id information, but I'm not sure that's really
> a /dev issue anyway (sounds more like a /proc/hardware/ issue).
The problem with this is that it adds one more program that _must_ work in
order for the system to be minimally functional. No devfsd ==> no /usr _at
all_, you can't even mount it by hand! And not because the filesystem is
shot.
I see all these proposals as introducing complexity for the sake of solving
problems that have already been solved (perhaps not with maximal elegance,
but with a working solution). Problems that aren't really important in that
they need to be addressed perhaps a dozen times during the lifetime of a
typical system.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/