Subject: Re: devfs, was Re: ptyfs fully working now...
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <>
List: tech-kern
Date: 11/29/2004 14:25:41
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 28, 2004 at 01:15:11AM -0500, der Mouse wrote:
> > My thoughts were that, with the binary file idea, we have explicit
> > atime, mtime, and ctime fields.  When the node gets updated, we note
> > the change and mark the internal entry dirty.  [...]
> Now, I have a question.
> At this point we are inventing a naming scheme for devices (so that
> changes of, eg, mode, or mtime) can be associated with the same device
> on subsequent reboots, stored somewhere, and read back next boot.
> At this point, I feel forced to ask: what benefits does this devfs
> offer over simply redesigning device nodes to use this new naming
> scheme instead of the <major,minor> naming scheme we've been using so
> far?  (I am not claiming there are no such benefits.  I'm just trying
> to compare devfs against "simply" redesigning device special files,
> which latter would automatically preserve many of the things we've had
> to worry about devfs preserving, such as traditional semantics for
> calls like chown and chmod.)

The biggest thing we gain with some sort of devfs vs new dev nodes is that=
we don't have to change any file systems; we aren't creating a new on-disk=
inode type.

The devfs-nodes-from-config-file (either binary or text) methods have the=
advantage that we need nothing other than a file from the root file system=
to get devfs going. It would even work on such antiquated fs's as msdosfs.

The devnodes-from-other-nodes approach needs very little from the root=20
file system. We _could_ make them work with files, but I think symlinks=20
sound like the easiest idea.

> In particular, I'm comparing, in my head, devfs versus redesigned
> device nodes plus a script/program that deals with devices that appear
> or disappear (as compared to the previous state); each one has its
> strengths and weaknesses, and I'm interested in our making as informed
> a comparison as we can.

Changing how device nodes are stored on disk would mean tweaking every=20
file system that supports them, and somehow creating this new on-disk=20
node. That also means other OSs will have issues reading our file systems.=
Either form of devfs means the underlying file systems don't change.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)