> > > True, but it works. It's no more kludged than some other stuff in the
> > > kernel (remember umsdos?). Less kludged actually.
> > If an ugly, evil klutz as umsdos is your standard...
> It's not my standard, but another example of an ugly kludge that works and
> is useful nevertheless.
But UMSDOS is a kludge to use clearly inferior infrastructure to get a work
done. If you are building something from scratch, you aren't forced to
build on quicksand. BTW, I believe UMSDOS has been broken beyond compiling
for quite some time now.
> > > Also, the current USB device naming system in 2.3.20 is a very ugly
> > > kludge that can go away with devfs.
> > It could go away in other ways to. Why _must_ it be devfs?
> Nobody is saying it _must_ be devfs (at least I'm not). Devfs is a
> possible solution though, and we have it right now, and it makes a lot of
> other things easier, especially for newbies.
I'd prefer to do this _right_, not "get something out the door _fast_". By
its nature, dynamic device handling impacts each corner of the kernel, and
as it shows to userland any decisions taken here will have to be lived with
for a _long_ time. Look at the current mess in /proc for a horror story at
hand.
> Advanced users who for whatever reasons don't like it can just turn it
> off.
But it is there, and has to be accounted for anyway.
> > > > - Breaks filesystem semantics in several ways, makes it very hard
> > > > to check ramifications
> > > How so? I don't see it breaking anything.
What if you need /dev under a chrooted environment (f.ex. ftpd)? There I'd
place a few devices, not everything. And perhaps even with very restricted
permissions. What if several copies of /dev are mounted? I chown something
in $HOME/dev/, suddenly a device becomes inacessible in /dev. Several
independent views of <whatever> are a breeding ground for races. Have they
been accounted for?
> > Persistence. Try adding ACLs cleanly.
> Cleanly: granted, this is a problem.
> Kludgy: possible without any major implications.
OK, but an ACL for a file (particularly a device) can run to tens of Kb.
Where do you store that?
> > > > - Impacts system administration,
> > > by making things easier...
> > ... and others impossible/hard.
> Such as?
Persistence is missing, or kludged on. Need to remember to edit, protect,
backup, check the "permissions file".
[...]
> > stability and security suffer.
> How so?
> I haven't seen stability problems with devfs even though I'm using it on
> Linux and FreeBSD.
Any extra code can introduce bugs, and there is just no possible protection
against bugs in the kernel.
[...]
> > > The key point being *for you*. There are people (PCMCIA, USB, Firewire,
> > > ...) who do add/remove devices frequently.
> > The _same_ devices all the time.
> Really? I, for example, use PCMCIA to connect my notebook with a D-Link
> DE640 to my home network, or with a Trust EtherLink PCMCIA at office...
> With USB hardware becoming more common, we'll see more problems like that
> - connecting computers (especially notebooks) to (different) printers
> everywhere, and that's just one of the examples.
> > Not that I want /dev/fd0 to appear when I place a diskette in it, and
> > dissapear when I take it out.
> This is different, because /dev/fd0 is the floppy drive, not the diskette.
> You still need to access /dev/fd0 if you want to probe if there is a
> floppy drive, or if you need to check if there's a diskette in it, and
> such.
I see no real difference in operational terms here. If no diskette is in
the drive, the drive might as well not be there at all.
> But you *don't* necessarily want to have /dev/usbprinter109 when the
> specified USB printer is not connected.
Does it hurt that much?
> > > - Makes handling hot-plug possible without ugly kludges
> >
> > See above. It is quite possible right now (heck, I do it with a Zip drive
> > reasonably often). Haven't seen any kludges.
>
> That's possible only because the Zip drive (parallel port, I presume)
> always connects at the same place. This is not guaranteed for connecting
> to chains of USB hardware.
Granted. But if will be at the same place most of the time. For now, while
a real solution is worked out, it does work.
[...]
> > Besides, device naming is a quite local matter;
> Until you start writing shell scripts that you want to use on your Linux
> and FreeBSD boxes without having to modify all the names.
But it's a matter of names. It doesn't mean that the names have to appear
magically. Scripts can't plug in devices yet, AFAIK.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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/