Messages in this thread |  | | | Date | Fri, 8 Oct 1999 02:21:39 +0100 (IST) | | From | Paul Jakma <> | | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) |
| |
Hi Horst,
On Thu, 7 Oct 1999, Horst von Brand wrote:
They are files (weird ones) in the Unix tradition that devices are files.
the files in devfs /dev are files too as far as userland is concerned. Unless you are referring to the fact that devfs is not implemented in VFS. I'm not clear on how that could be a problem.
(it's either 100kb of fs static /dev, or 100kb or devfs in memory)
The standard interface is that permissions stay put, even after reboots.
true. with devfs it would be nearly the same. ie:
- devfs /dev is mounted at boot, all devices created with default *tight* permissions, eg root.root 600.
- userspace devfsd is started, consults config file and sets permissions on devices accordingly. (not retroactively with the current implementation of devfsd, but that can be changed)
Fine example of the technical excellence and open-mindedness requested above.
indeed. if we're to get anywhere with this debate we need to keep flames out of it. (i'm guilty there too) :).
Reasons against devfs:
- Permanent attributes are kludged on
they're implemented via a daemon/config file. which sounds good to me. (no tar kludge).
- Breaks filesystem semantics in several ways, makes it very hard to check ramifications
interesting. in what way exactly? i've been using devfs for a while and havn't noticed any problems to do with broken fs symantics. Ie, i can chmod/mknod/touch file/mkdir.. etc.
- Impacts system administration, making device managing a lot less Unixy
i think it will simplify system administration, once devfsd retroactively applies permissions. ie: the ability to set /policy/, to say "all devices of class ABC should be xyz" is very powerful.
certainly daemon + text config file is VERY unix way of working. See /etc for example.
- Impacts _every_ single driver in the kernel, even if it isn't used
true.
But, the change is minimal. The devfs {un}registration mechanism is very similar to existing major/minor number {un}registration. And any driver that currently has a /dev node can be easily adapted for devfs. eg, something like: old way:
register(major, minor, ..)
devfs:
devfs_mkdir(string, ..) for (number of devices) devfs_register_node(string, flags)
not really a big change.
Reasons for devfs:
- Makes handling hot-plug easier, but marginally so
i'd disagree with the marginally bit. in fact i'd say hot plug and static /dev will be a gross hack of complicated scripts. Much more difficult to set policy inside a script. - Unclutters /dev
- it allows for location based device nodes without having to add a huge amount of nodes.
eg my must have feature of devfs is the SCSI disk device naming based on controller/id/lun/partition. With static /dev you would need a huge list of nodes for all the different possible combinations.
(i'm aware of the scripts to create symlinks, but that really is a kludge)
Also: It is extra code, has to be maintained and updated, and has to be accounted for in new driver developments. It _will_ add new bugs, even new classes of bugs. This doesn't come for free.
that's not really a valid argument. If that were a reason against devfs, then we should stop all further kernel development - it too will add bugs.
Weighting the above, the answer for me is clearly "no".
well i like the idea of devfs. IMO it will aid drivers that handle hot-plug drivers and it will make /dev permissions integrity more robust. It also makes more efficient use of dev_t space, which makes location_based nodes possible.
Anyway... I think we've heard all the arguments by now (many times) So let's wind this argument up. We're all sick of it by now.
regards, -- Paul Jakma paul@clubi.ie PGP5 key: http://www.clubi.ie/jakma/publickey.txt ------------------------------------------- Fortune: In 1914, the first crossword puzzle was printed in a newspaper. The creator received $4000 down ... and $3000 across.
- 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/
|  |