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

On Thu, Nov 18, 2004 at 02:13:26PM -0500, Chapman Flack wrote:
> Bill Studenmund writes:
>=20
> > I uesd to think some idea using on-disk device nodes would work, but I
> > don't anymore. Why shouldn't we just synthesize the whole thing from
> > scratch?
>=20
> The answer to the last question is, obviously, that we need ownership and
> mode changes to be persistent.  Any solution is going to have to provide
> some form of persistence for those data, with update integrity and recove=
rability.
> The central question in this thread is the representation for the persist=
ent
> data.  Eric's suggestion was one possible representation; other suggestio=
ns
> have included a text file stored beneath the mount point, and binary files
> containing similar information.  Some of the tradeoffs have already been
> covered.

Uhm, I'm the person championing the binary file approach, so "synthesizing=
=20
from scratch" will, at least for what I'm talking about, retain=20
persistence info.

> I think you're spot on when you point out there are two namespaces.  Part
> of what we need to maintain in some persistent store is the mapping betwe=
en
> them.  (For some devices you won't care.  But for some you will want to
> assure that the same node name is reliably associated with the same devic=
e.)
> That mapping will be done in the kernel or out of it (those are the two
> obvious choices).  Doing it in the kernel requires making the node-name-s=
pace
> visible in kernel-land, say by a suitable extension of config(9) language
> that allows expressing node names.  Doing it out of the kernel, conversel=
y,
> requires making the driver-locator-name-space visible in user-land, say by
> a convention for canonical locator-based names in a devfs a la Solaris.
> (It was pointed out earlier that there's really a third approach, which is
> to invent a third namespace like dev_t that must be mapped in both direct=
ions,
> but I think we agree part of the point of a devfs is to get rid of that
> complexifying layer.)

No one is very interested in the userland-exposed option.

What Christos and I were discussing is doing the node-namespace=20
manipulation in devfs, and saving the file in the (root) file system.

> The difficulties you point out with renaming and so on are not difficulti=
es
> with any one choice of representation for the persistent owner/status dat=
a;
> they will be consequences of any scheme that fails to provide a reliable =
way
> to name things in locator-space, regardless of the concrete representatio=
n.
> So it's a side issue as far as representation choice is concerned.

Actually, I don't think it's a side issue. I think the issues are due to=20
being sloppy about the name spaces. The representation initially discussed=
=20
was rather sloppy about representations, and so the complaint is not a=20
side issue.

Take care,

Bill

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

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

iD8DBQFBnVUKWz+3JHUci9cRAqoHAJ4tq5J8SdyKvA9UIhC9c6g4Oc+zXwCdHCdw
9qbVNxDtuM6C8kBxOqYepBE=
=6Y/x
-----END PGP SIGNATURE-----

--GxcwvYAGnODwn7V8--