lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
H. Peter Anvin writes:
> >
> > Obviously, I do think there are problems that devfs solves.
> >
> > BTW: why was autofs implemented given that amd existed? Apart from a
> > bug with the handling of wildcards, amd seemed to work for me. What
> > was is that you couldn't do in userspace that required autofs?
> >
>
> Actually, the bulk of autofs *is* in userspace. However, amd has
> constant problems, both performance- and correctness wise, due to its
> emulating an NFS server. amd requires a context switch on every
> access that crosses the automount point, which leads to very poor
> performance, and the necessity for using a secondary mount point
> rather than mounting directly on the automount point proper is a
> constant source of failures. The kernel stub allows for the common
> case (which is, no mounting/umounting needed) to not invoke userspace,
> and to provide a clean interface to the VFS, while the hard stuff
> (mounting, umounting) is done in userspace.

So, in essence you had something implemented in userspace but you put
kernel support in to:
- improve performance
- provide a conceptually cleaner system.

So you provide a basic interface in the kernel to support something in
userspace, where you design an interface specific to the userspace
component.

> This is, in fact, analogous to saying that device nodes are kernel
> concepts (which they are), but the management of them (which doesn't
> need to be fast) belongs in userspace.

I agree. I see devfs as providing a basic interface (which improves
performance and provides a conceptually cleaner system) for
userspace. Something like devfsd can provide the policy. Devfs itself
(well, actually the individual drivers) provide a basic default policy
(a minimal policy) and userspace can do the rest. However the
interface has been designed specifically for the userspace component
(devfsd) that provides the policy. I see the existing rc.devfs script
that can tar/untar permissions as a more primitive userspace policy
component.
However, I don't expect you to see it this way ;-)

BTW: one way I can see devfsd being used is that devfs is mounted onto
/devfs or some such, and devfsd fills a disc-based /dev with symlinks
to /devfs, or creates real device nodes. This would satisfy people who
don't like the default policy of devfs (permissions and naming
scheme). In this way devfs becomes an information provider, one that
is unified for all devices.
Not that I expect to use it this way myself, but the possibility is
open.

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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.067 / U:0.288 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site