> True. Use rm(1). Note "not used" is not the same as "device is not present
> right now". F.ex, I want /dev/fd0 stay around if only to carry permissions
> for floppies I insert into the drive.
/etc/fstab covers static values of things, any given config file can. quota
files cover storage of the kernel's in core map when the kernel isn't running.
> The static solution does exactly this (small wonder, the filesystem was
> designed for this kind of task). No overhead, no daemons, no database to
> corrupt/destroy, no screwy implementation with callback to userland daemons
> for the simplest system calls on files. Minor blemish: It is not dynamic,
> so it seems it is just impossible that devfs advocates see that it solves
> almost all the hard problems they want to have solved. The ones left aren't
> solved by dynamic schemes either, so they don't count anyway.
people want storage of in core data one way or another, from quotas to devfs
to network routes and firewall rules.
it's not so different than the similar suspending to disk concept. when you
start, load the maps, when you end, save them. at all other times, operate on
in core data.
> So going into the store and shelling out a grand for modems is not too much
>
> work, but after setting the bunch up (say a half evening more) it is way
> too hard to do:
>
> for m in $(cat /tmp/newmodems); do
> MAKEDEV modem$m
> done
> I just don't get it. Even if you have to hack MAKEDEV to recognize modems,
> and set them up with your defaults.
so if i spend a grand for my modems, i should also hack up scripts? why
should i even go through the bother of the for i in x and just let them
automagically and correctly appear in /dev?
your logic escapes me. because you feel writing little scripts to do all this
maintenance is within your grasp, you think everyone should do it your way?
> [...]
>
> > The point I'm trying to make is that if properly implemented, a
> > dynamic device system should be transparent to the system and the
> > users, but gives them the option to configure it in many ways to suit
> > their preferences. Surely that is a win-win situation all round?
>
> The current scheme is totally transparent, without any extra crutches to
> get it limping along. So it is a loose-loose situation.
it's spelled "lose lose" Doctor. devfs is by no means a losing situation for
me, *I* win.
> I'm not arguing against devfs, I'm arguing against the idea that a dynamic
> naming scheme for devices will magically manage your devices for you. It
> just can't.
it does magically manage my devices, very nicely too.
> > I've never used devfs, but I like the idea behind it.
> > I'm totally unbiased because I know nothing about the implementation
> > of devfs or traditional devices,
>
> Then you can't know how much this costs, kernel-wise.
nor can you know how much devfs benefits me.
> for i in 0 1 2 3 4 5; do
> MAKEDEV usb$i
> done
>
> is so hard that the kernel _must_ do it for you?
yes. i want the kernel to do it for me because the kernel won't make mistakes
and always matches the running state, nor do i require an admin to run
scripts.
why are you so adamantly refusing the conveniences and ease of use it affords
those of us that use it? why do you insist we rely on hacked up scripts?
-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/