--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 18, 2004 at 08:26:27PM -0600, Eric Haszlakiewicz wrote:
> On Thu, Nov 18, 2004 at 10:29:38AM -0800, Bill Studenmund wrote:
> > Why is that better? That would be a very messy to code, and we have som=
e=20
> > very messy naming issues. We seem to have two name spaces, that of node=
s=20
> > on the disk and that of devices. Sometimes the namespace for devices sh=
ows=20
> > up, sometimes it doesn't.
>=20
> 	I don't think it would be any messier than writing code to store
> the information in a file instead of a filesystem.  With the file
> as the backing for persistent state you have two name spaces: that
> described by the file and that described by the devices the kernel
> has at a particular moment.  Regardless of what the backing store is
> those two need to be merged.

I think it would be messier in two ways. 1) you have two file systems
involved. So you have up to two vnodes involved in everything. And you
have three classes of vnodes: devfs-only vnodes with no underlying node,
devfs device nodes with an underlying node, and devfs other-nodes with an
underlying vnode. While an overlay file system can do that, it's messy. 2) =
=20
You're still relying on "traditional" node names to identify the device. =
=20
One of the big advantages I see of a devfs is that we can now use locators
to identify devices. I mainly see it in terms of disks on a SAN, but using
locators can make a lot of stuff work quite nicely. Like you can have an
office/work group machine that different folks hook USB sticks into. We
remember device permissions and tie them to the S/N of the stick (I admit
I am assuming they are sticks with real S/Ns). When Alice plugs her stick=
=20
in, it gets set up so she gets exclusive access (which is how she wants=20
it). When Bob sticks his stick into the computer, he has exclusive access.=
=20
Doesn't matter if the sticks show up as sd0, sd10, or sd32.

> > I uesd to think some idea using on-disk device nodes would work, but I=
=20
> > don't anymore. Why shouldn't we just synthesize the whole thing from=20
> > scratch?
> 	I think you're missing my point.  There _aren't_ any on-disk device
> nodes.  The only time a device node appears is when it is synthesized
> by the devfs.  devfs uses the on-disk state to modify how the in-kernel
> devices appear to userland.  Let's take the rename a device node example:

No, I got that point. I had that point, and I argued it for years. I now=20
think it isn't a good one. I think it ends up being quite cumbersome.

Read my reference to "on-disk device node" to mean a node on the disk,=20
either a file or symlink, that contains info for a device node. I did not=
=20
specifically mean that it has to be a char or block dev node in the=20
underlying fs.

Take care,

Bill

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

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

iD8DBQFBnk7bWz+3JHUci9cRAmMmAKCBUy5BDV4qo6YG4zU0IyJE0FbLFQCfdCcO
ZWPz2wEFySvmC8dX/N/a7Qc=
=5Cff
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--