[...]
> Don't be scared of that. Devfs means dynamic devices directory. And
> chown/chmod never worked well in dynamic situations. You certainly
> don't expect
>
> chgrp lp /var/spool/lp/* && chown u+rw /var/spool/lp/*
>
> to produce any permanent results.
Very true. The files in the print spool aren't permanent, and shouldn't
be. But what has that to do with the permissions on my quite permanent (I
hope) hard disk, tape drive, modem, and so on?
> You have to reconfigure (or even
> recompile) the print service to get different permissions. Another
> example: Permissions for new mail folders created by my MUA are
> compiled into /opt/bin/mutt. Not even a configuration file.
"New mail folders when created". You can change the permissions if you want
to, and the new permissions stay put, don't they? That's exactly what I
need for devices!
> If /dev is frequently cleaned up by a script and re-populated with
> MAKEDEV whenever new hardware gets attached the situation is the same.
Wrong approach. Check for _new_ devices, add them via MAKEDEV with default
permissions; think a fev seconds (or agonize for several days) on the
permissions they should have. Set permissions, and go on with life.
> The configuration file for permissions/ownership would be MAKEDEV.
It is, for _default_ values. Sure, you could update it each time. Or make
it take default permissions from a configuration file. no big sweat.
> It would be enough for devfs to remember permission/ownership changes
> of a device file until it gets deleted to retain Unix-style behaviour.
Great idea! That is just what the boring ext2 gives you.
> And a reboot can mean deletion of all device files. I don't see
> anything wrong with defining access/security policy for hardware
> devices in a configuration file.
I do. That way you can't get back the configuration you had when power went
down. It means throwing out (for no good reason, to boot) the whole idea of
"a device is a file, and is handled exactly like any other file" that is
one of the cornerstones of Unix. I.e., chown(1)/chmod(1)/mv(1)/rm(1)/ln(1),
also tar(1)/cpio(1) won't work as they should. Note the (1), those are
down-to-earth, everyday Unix commands. And you propose to break them just
like that.
> The one change that you have to accept (if you decide to use devfs, or
> any other method for dynamic device files) is that /dev won't be static
> anymore.
That isn't exactly a minor change. How would you feel if your files went
"dynamic" and got a name depending on the phase of the moon, and even might
suddenly dissapear from under you? OK, I'd buy a dynamic system if I got
something in return, What I see is just nebulous talk about managing
hundreds of devices that just come and go. Handling hundreds of devices
isn't an everyday task, so when I hit a system like that I'll either sit
down all day and configure the devices, or write a script for that. After
that, they'll sit there until it is time to add/delete/reconfigure one of
them. Systems with hundreds of devices that come and go without human
intervention are just figments of somebody's imagination. At least nobody
with that exact, hard pressing problem, for which devfs is supposedly the
magical bullet has spoken up here.
Even in you assume that devfs does work, what do you do if suddenly
/dev/mouse471 appears, followed by /dev/sd781; and then a bit later
/dev/sd215 dissapears? No big deal, unless /dev/sd215 just happened to be
your $HOME. In that case, no devfs will save you. The mouse and the extra
disk won't be of any use anyway if nobody cares enough about integrating
them into the system. devfs (or any naming system, for that matter) can't
do that, as this is strictly policy. And if you want to do this to $HOME,
use the automounter, it is quite capable of mounting devices on demand.
-- 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/