Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

H. Peter Anvin (hpa@transmeta.com)
11 Aug 1998 22:50:34 GMT

Followup to: <Pine.LNX.4.00.9808120741560.2419-100000@stoli.spirits.org.au>
By author: Nathan Hand <nathanh@chirp.com.au>
In newsgroup: linux.dev.kernel
>
> On Tue, 11 Aug 1998, Theodore Y. Ts'o wrote:
>
> > Date: Sat, 8 Aug 1998 21:35:28 +1000
> > From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
> >
> > The reason I think that persistence is a side issue is because adding
> > it will not change the API nor the way the devfs internal management
> > is done. However, I expect we'll continue to disagree on this point.
> > That said, I'd rather look to the future. I'm currently considering
> > two options for persistence:
> >
> > - using a block device
> >
> > - peeking through to the underlying disc-based inodes.
> >
> > Ted, do you have any particular preferences/suggestions on this?
> >
> > My preference would be to store the inodes in the filesystem. If you're
> > going to be using a user mode daemon anyway, as you've suggested in
> > other mail messages, then let's define a well-defined interface for the
> > kernel to notify the user mode daemon that new devices has apeeared
> > (either at boot time or due to a PCMCIA/USB/1384 device getting
> > inserted), so that the user mode daemon can create the devices as
> > necessary.
>
> I like this suggestion. It opens the door to having an /etc/dev.conf
> with permissions, ACLs, post-scripts, user-defined naming schemes (I
> think that would solve most people's problems immediately :-).
>
> But isn't this remarkably similar to the kerneld idea?

Yes, it is very similar to kerneld/kmod. I think it wouldn't be a bad
idea to expand that mechanism to support this kind of stuff.

> I especially like the idea that modules still notify something there
> is a need for a /dev - so /dev remains dynamic, only shows you those
> devices which exist, etc - but very little exists in the kernel.

Even better -- the modules can actually store this information in an
additional ELF section (as we already do), and this stuff doesn't have
to go into the kernel at all.

> > This follows the fundamental principal of keeping policy out of the
> > kernel (an argument which you yourself have advanced), and doing as much
> > as possible in usermode. Performance won't be an issue, since if the
> > user-mode daemon is automatically creating the devices, you won't have
> > "8 million devices" in /dev (despite that favoriate devfs strawman
> > argument). True, lookups will still have to go through /dev, but the
> > dcache pretty much obviates that argument. (Also consider that opening
> > devices is generally in the noise as far as most applications are
> > concerned. It's hardly a common case that we need to optimize.)
>
> The only issue is that you then lose /dev on filesystems which don't
> support UNIX nodes (ie devfs on ms-dos partitions). Though there are
> other ways of achieving the same effect, so it's no big loss.

You can't have that anyway; devfs is the logical equivalent to
mounting a ramdisk (which can always do this), but for MS-DOS
filesystems in particular you have umsdos/uvfat, and I think this is
the correct solution.

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bahá'í -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misérables


-
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