> The standard interface is that permissions stay put, even after reboots.
use the config file. we have config files for mounts, we have config files for
modules, etc.
> Reasons against devfs:
>
> - Permanent attributes are kludged on
as are attributes on a variety of items. dynamically changed attribs can be
done with scripting, daemons; userland or kernel. this is a 1:1 debate point.
> - Breaks filesystem semantics in several ways, makes it very hard to check
> ramifications
how? should we throw away /proc and other magic filesystems because they
aren't true blocks of data on physical disc media?
> - Impacts system administration, making device managing a lot less Unixy
how? i've been using devfs for well over a year and i find managing devices
much easier and less time consuming. "unixy" needs to keep pace with today's
technology needs. devfs is certainly a step in that direction.
> - Impacts _every_ single driver in the kernel, even if it isn't used
there's a good lot that impacts every single driver, memory routines come to
mind. function naming semantics, etc.
> - What can be done with devfs can be done without it. Granted, it is less
> convenient. But I add/remove devices from my machines perhaps once a
> month, so that doesn't cut it for me.
i have pcmcia and hotswap items everywhere. i transfer hardware *frequently*.
devfs makes things easier. with the amount of admin work i do, convenient
administration is terribly wonderful.
> Reasons for devfs:
>
> - Makes handling hot-plug easier, but marginally so
> - Unclutters /dev
makes handling devices exactly correct. /dev/sda could be any of disc.
/dev/sd/c0b0t0u0 is precisely one disc.
an uncluttered /dev/ is immensely make-me-happy helpful. i have several
systems with LARGE process tables that do a lot of work in /dev. having a
dynamic /dev is considerably helpful in keeping the file op load down.
> Also: It is extra code, has to be maintained and updated, and has to be
naturally...everything more is ... more. it's been splendidly maintained and
updated for the last two years since it's inception.
> accounted for in new driver developments. It _will_ add new bugs, even new
> classes of bugs. This doesn't come for free.
in my experience, devfs has uncovered existing bugs in other software and fixed
such things as tty ownership and permissions. remember all the dribble about
*xvt and tty permissions?
> Weighting the above, the answer for me is clearly "no".
then you may certainly answer "no" when you scroll past it in your config
options for building the kernel. i will clearly choose "yes" just like i do
for every other option i need in my kernel.
should we remove all portions of the kernel with SMP in it because you may not
have an SMP machine?
this is a silly debate. would you also argue that pcmcia shouldn't go in the
kernel because you may not have pcmcia?
-d
-- This is Linux Country. On a quiet night, you can hear Windows NT reboot! Do you remember how to -think- ? Do you remember how to experiment? Linux __ is an operating system that brings back the fun and adventure in computing. \/ for linux-kernel: please read linux/Documentation/* before posting problems
- 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/