lkml.org 
[lkml]   [1999]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site