Not true. You can map vast major/minors to files, you know.
> I for one happen to find having a bunch of files in /dev that aren't
> used to be a mess (yes, I could go and remove the ones I don't need,
> but they shouldn't have been there in the first place). I would much
> prefer it to be dynamic, but I don't care that much if it is a kernel
> space or user space solution (although user space is probably better).
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.
> The big problem people seem to be bitching about (and some of you
> really are being bitchy about this) is persistance of
> ownership/permissions on these device entries over reboots.
> Now, I assume that when you chmod or chown a file (or in this case, a
> dynamic device entry), the underlying fs is told that it has to
> perform this change. At this point, the code responsible for handling
> the dynamic devices can store this information along with some
> information to uniquely identify the device connected (maybe a
> combination of it's location on a particular bus, or a unique serial
> number - whatever, that is a detail for the implementors to
> determine). Doesn't this now cover all the major problems with a
> dynamic solution?
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.
Also note that the "callback to userland" scheme that was in the kernel was
scrapped some time ago as too fragile and too much overhead: kerneld became
kmod.
> If you have a userspace daemon and it is smart enough, you would be
> able to produce complex rules regarding these dynamic devices, for
> example, if I want to have an ISP running off my box with 512 USB
> modems, I create some kind of rule in the userspace daemon's
> configuration that all USB modems will be owned by user x and given
> specific permissions. If I later want to add more modems, I just plug
> and bunch in and they automatically get the right
> permissions/ownership set on them.
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.
[...]
> 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.
> Arguing against a dynamic driver system because you don't like an
> existing implementation of it seems, to me at least, to be a complete
> waste of time.
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.
> 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.
> but I see dynamic devices as a
> convienient solution to a very sticky problem (I probably wouldn't be
> very happy if I did a MAKEDEV usb to find 255 new entries in /dev when
> I only use a couple of USB devices and even then only very
> occasionally - this also applies to the distros who seem to assume
> that we are too dumb to mknod our own devices so they create hundreds
> of the damn things for us).
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?
-- 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/