--GvXjxJ+pjyke8COw
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.  [...]
>=20
> Now, I have a question.
>=20
> 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.
>=20
> 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=
=20
we don't have to change any file systems; we aren't creating a new on-disk=
=20
inode type.

The devfs-nodes-from-config-file (either binary or text) methods have the=
=20
advantage that we need nothing other than a file from the root file system=
=20
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.=
=20
Either form of devfs means the underlying file systems don't change.

Take care,

Bill

--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBq6HlWz+3JHUci9cRAsMtAKCSCn4ssuCyts0OL82YWM9Xg/PAmwCePvJF
Z+CdSVk60bPt/x1XjpeoHZ8=
=+P0a
-----END PGP SIGNATURE-----

--GvXjxJ+pjyke8COw--