lkml.org 
[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)
On Thu, Jun 17, 1999 at 06:14:47PM +0100, DAVID BALAZIC wrote:
> An opinion about /dev :
>
> In the old system /dev is a collection of "links" from
> filenames to device numbers (major:minor).
>
> With devfs it could be a collection of links from
> filenames to /devfs/* entries.
>
> The first one is done with device files , the second
> with symbolic links. In both cases /dev is a normal directory.
> In second case devfs is mounted somewhere else.
>
> With this second case there is no problem with policy,
> since in that regard is is equal to the first case.

Except with this scheme you still have the perms/uids/gids problem which
leads to nasty tarball hacks inbetween reboots. Remember symlinks obtain
the permissions of what they point to but /devfs is virtual and will not
preserve permissions when the system is down.

> The difference is that the "kernel connection" is not based
> on device numbers , but devfs created names.
> The good side is that ...
> I think I forgot it :-)
> But this way adding a new disk into system doesn't cause
> /dev entries to "skip" ( point to a different physical device
> than a day before ).

It's also messy, because /dev entries don't go away when they are not in
the system or unavailable for another reason (say, suspended, or powered
down). It also doesn't address the issue of automatic device creation if
you access a non-existant entry in /dev (and glibc hacks are more odious
than kernel hacks here). Also it means you have a symlink lookup on each
node access, which is vaguely stupid. Also I don't think there are gains
from a symlink tree in /dev: the problems have just been moved from /dev
to /devfs, but they are still the same problems (policy in /devfs should
be avoided just as much as policy in /dev).

I don't like this scheme at all. It's messy, gains little, loses much, &
adds complexity without solving the real problems (naming policy isn't a
kernel issue, preserving permissions over reboots, automatic device node
creation upon access, removing stale nodes when module is gone).

--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au

-
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:52    [W:0.963 / U:27.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site