> > What I want to say is that your "solution" creates more problems than
> > there were before. The Unix way (/dev is part of a real filesystem;
> > permissions, ownership, names, links, ... all work the same as with
> > regular files) is a time-tested design. Not flawless, but its flaws are
> > known and workarounds are in place. You propose to junk all that for a
> > shiny, new way of doing things that does break in many ways (see
> > above).
> arghhhh... horst, devfs supports ownership, names, links, pipes, etc just
> like normal ext2 /dev... and persistence via a daemon. IIRC the only
> difference between devfs and ext2 /dev is that devfs bypasses VFS.
And an daemon does the work, so if the machine is overloaded or chashes the
above just isn't done. "We support XXX, as long as we have shiny weather"
isn't enough.
> you've been told this already.
Nope, I've been told over and over again that it is handled, but it
isn't. You said it again: Persistence is _not_ handled.
> > Note that just devfs does _not_ solve the "more devices"
> > problem, as long
> > as major/minor stay limited.
> it does solve it. As devfs can allocate major/minors dynamically at
> run-time, rather than the old way of having to pre-allocate major/minors to
> all possible permutations of devices.
And how does each device get addressed inside the kernel then? The
major/minor stuff used to be an array for major, and each driver (indexed
by major) decides how to handle minor. Not a minor change to the kernel in
my book.
> you've been told this already.
Again, I've been told that this is solved, and the solution you outline is
massive work, yet to be done, in the kernel. Work that will have to be done
to solve the problem of huge numbers of devices anyway.
> > It can't really solve the "unplug sda, now sdy is sdx" problem either
> > (somehow devices _must_ be named, and this has to be done somehow
> > fixed, you can't just lug around the whole history of /dev), and it
> > can't solve the "unplug sdc, plug in another sdc, and then sdd; now
> > plug in the old sdc and have it be sdc again" problem.
> devfs solves this perfectly. the reason being that the driver does know at
> runtime which disk is on which controller/bus/id/lun. And so the driver can
> register disks with appropriate names like c0b1t2u0.. etc.
Great! And if I move the disk from one controller to the other, or switch
it around on the chain (or change its SCSI target in some other way) it
changes name. So names aren't persistent after all... and if the driver
does know where the disk sits, it could just as well export that knowledge
through the major/minor it reacts to. No dynamics required at all, probably
much simpler than the current scheme.
> this has been stated already.
Yes, but you are just changing one set of names, which has flaws (the
device renaming problem) with another with flaws that are equally serious
(devices get renamed when moved). In _both_ cases devices get renamed. In
the /dev/sdX case, when you remove devices, but not always when devices
move. In the /dev/cXtYdZsW case, they get renamed when devices move, but
not when devices get deleted. In the case of a PC, if you change your SCSI
adapter, it will probably now be somewhere else, so just changing the
controller will move your disks. This is deadly, so the sdX scheme is a bit
better there than the cXtYdZdW scheme. Both are bad, both can be done
without fancy dynamics. A kludge around this is mounting by label, which is
closer to what you really want: You want to mount whereever /tmp used to
be, the physical platter that is. That the device is now called
/dev/c15t13d5s117 is irrelevant, as it was yesterday when it was
/dev/sdf14. Device names are just convenient handles to device contents,
packaged up in a way easy for the operating system to export, and simple to
handle with standard tools for the userland. Just like you don't care much
about the inode of your .bashrc, forget this silly naming game.
> > Any solution it
> > could offer for this
> [ above slightly out of context ]
> ok, rather than just saying "no.. no.. no..". Why can't we have a
> constructive argument where you say "no, you'd probably need to do it
> something more like xyz".
Because constructive arguments do have to include "This can't work. Better
look for another way to get there." somewhere.
-- 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/