>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?
It's good you are at least trying, but you are ignoring
the fact that drivers even exist. It is the drivers
responsibility to prepare and adjust for possible races.
Besides, your scenario is no different from having multiple
regular device nodes, which, BTW, you can still do with
devfs, and this scenario is dealt with by the driver. If
it were up to userland to avoid racing drivers we'd all
be knee deep in bullshit bugreports.
>> 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?
Please don't add ACLs as an argument against devfs.
It's dumb.
>> 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.
Which is why it's been tested for YEARS.
>> 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.
It should have a reserved *spot* in a chain if the DRIVE
exists.
>> 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.
Explain EXACTLY why devfs isn't REAL? I don't see your
time tested kernel patch... I really suspect your Dr.
title is fake, and that's not a joke.
-Shawn
-
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/