lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)
Nathan Hand writes:
>
> On Sat, Jun 19, 1999 at 06:44:11PM -0400, Horst von Brand wrote:
> > Nathan Hand <nathanh@chirp.com.au> said:
> > kmod + modprobe are doing fine, thanks.
>
> These tools do not (and can not) insert modules based on attempts to
> open non-existent device nodes, so I fail to see how they do
> fine. You've just thrown away one of the best features of the
> virtual /dev.

Exactly.

Further, with devfs you could pass lookup events for non-existent
inode to devsd, which could then decide what to do. Right now devfs
just passes the event to kmod, which will load a module. If the event
is passed to devsd instead, then devsd could authenticate the module
load request (or do something else entirely, depending on
/etc/devfsd.conf). This works (unlike kmod), because devfs knows who
tried to lookup the inode.

> > OK, I could look it up
> > in a magic place in /proc... but if I don't want to mount proc (perhaps for
> > security reasons, or whatever)? Anyway, now I'm dependent on a magic file
> > in /proc (with _that_ specific format!) that does not exist anywhere else
> > (bye, bye portability) _and_ /dev, and perhaps more stuff. Also, the above
> > might give rise to races.
>
> This is all just fantasy conjecture. It's better to argue against
> what is being proposed, instead of these idiotic designs that you're
> inventing to make devfs look bad. There is no magic /proc file.

Even better, make arguments against what is actually implemented,
rather than an invented devfs which works in an illogical way. I can't
even imagine implementing a devfs that needs some strange /proc
parsing just to deal with a ZIP drive. It's a really strange idea.

Don't people ever bother to download things and check them out before
criticising? Or is the blindfold only applied to devfs? I'm amazed at
the number of funny ideas that have been raised in this thread, which
are:
- completely unrelated to the devfs I've implemented
- completely unrelated to anything that resembles a halfway logical
implementation of a devfs.

> > And "Need Zip drive... OK, look how it should be called today...(root
> > around in /proc)... OK, it's called /dev/foo today, go access /dev/foo so
> > the kernel goes looking for it... nope, not found" sounds harder on the
> > user than "Look for /dev/zip (or whatever it is called _always_ in /dev),
> > if not found give up".
>
> What?

Ditto.

> > Many programs will just go /dev/foo, and introduce subtle bugs.
>
> What bugs?

Phantom bugs, I think.

> > The problem with this is that it adds one more program that _must_ work in
> > order for the system to be minimally functional. No devfsd ==> no /usr _at
> > all_, you can't even mount it by hand! And not because the filesystem is
> > shot.
>
> Yes, you can. You create the nodes with mknod. This is a non-argument.

Even better, you don't need to create nodes because drivers create
usable ones. That's why you can boot a devfs kernel without devfsd.
Nice for an embedded system.

> > I see all these proposals as introducing complexity for the sake of solving
> > problems that have already been solved (perhaps not with maximal elegance,
> > but with a working solution). Problems that aren't really important in that
> > they need to be addressed perhaps a dozen times during the lifetime of a
> > typical system.

This is a joke. Devfs is a very simple, lightweight and robust
system. Anyone who has looked at it knows that. If you want a
conventional static /dev, then don't use it. If you want a dynamic
/dev (and even some of the most vocal devfs opponents agree that a
dynamic /dev is good), devfs is much more elegant and simpler than any
of the alternative scheme yet proposed. And of course devfs has
features that the other schemes dont'

> I think you intentionally try to misunderstand or misrepresent what
> devfs does. The nonsense above about "magic /proc entries" and "race
> conditions when opening devices" and "changing device names"
> suggests you have never even seen devfs, let alone made an informed
> decision about it.

The only "race" condition with devfs+devfsd was a minor permissions
one, and that was fixed in devfs-patch-v111.

Regards,

Richard....

-
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.055 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site