Subject: Re: devfs (was Re: Not updating device file inode change times)
To: None <tech-kern@netbsd.org>
From: Eduardo E. Horvath <eeh@one-o.com>
List: tech-kern
Date: 09/04/1998 20:51:08
On Fri, 4 Sep 1998, Todd Vierling wrote:
> [Pipe dream brainstorm]
>
> Make /dev be mounted dynamically inside the kernel at boot, before init is
> run. This guarantees the existence of /dev/console, and allows the
> underlying /dev directory to be completely empty.
>
> devfs would be a layer filesystem of its own, who would check the lower
> layer for files that do not exist in devfs, and files with the same name as
> devices which contain only:
>
> - file access and modification times
> - file ownership and permissions
>
> which would be modified in the lower layer as necessary. If there is no
> backing file in the lower layer for a given /dev node, it is created at any
> time that one of the above needs to be changed (0 bytes, similar to a
> "touch"). A special value for mtime (0, perhaps) would indicate a
> "whiteout" to the devfs such that nodes could be deleted.
>
> This doesn't handle renaming nodes, unfortunately. However, it does allow
> nodes to have symlinks inside /dev.
>
> Devices needing nodes would need to export names for devfs to create the
> necessary nodes. This would probably be some kind of callback hook passed
> into the attach function.
[I suppose I could edit away parts of the pipedream, but it supports my
argument soooo well.]
Definition: I use the term devfs to describe a pseudo filesystem generated
by the kernel similar to /kernfs.
Historically, the primary argument against a real devfs /dev is that it
does not persist across reboots, so any permission changes made to device
nodes go away. Solaris decided to go with a standard ufs filesystem with
a whole bunch of little kernel-grovelling mknod and symlink generators.
But that has long been a source of problems.
My original suggestion was that all you need to do is create a devfs
capable of automagically creating standard device nodes. unionfs should
already be capable of doing the rest. You can chmod something or copy it
or rename it or delete it. All we need to do is make sure it works with
device nodes as well as files, and fix all the annoying unionfs bugs.
Generating a devfs is a large enough project in inself that providing
persistence (or unionfs-like properties) is best left to other means.
The only problem I see in my original idea is somehow getting the devfs
filesystem mounted underneath /dev. But I think mount should be capable
of doing this.
Now for NFS mounted roots you could mount the devfs filesystem on top of
/dev or make the nfs mounted /dev read-only since there is no real need
to provide persistence. If you really think you need persistence on a
diskless client you can simply copy the device nodes from the devfs /dev
to the NFS /dev using tar or dump/restore or some script that greps each
node's major/minor and then does the proper mknod to clone it....
=========================================================================
Eduardo Horvath eeh@one-o.com
"I need to find a pithy new quote." -- me