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

On Sun, Oct 03, 2004 at 06:48:27PM -0700, Bill Studenmund wrote:
> >=20
> > It depends on what aliases are going to be. Are they true aliases
> > (multiple indistibguishable names for the same thing) or is one of the
> > names special somehow.  Without meaning to imply anything about
> > potential devfs implementation, the analogy is of symlinks vs
> > hardlinks in a normal filesystem.
>=20
> My thought is that one name would be special, so aliases are more like
> symlinks.

Sure.  But what is that name?  Perhaps its more like a GUID?

I guess I'm leaning towards the thought that issues of naming,
aliasing, and collision/uniqueness more properly (or at least more
conveniently) belong in a devfs discussion.  For one thing, there are
established interfaces and userland tools to manipulate the namespace.
For another, naming collisions and aliases can by necessity arise in
any order, using any combination of in-kernel and userland
wedge-creating tools, and are perhaps thus best resolved by removing
them from the wedge-tools entirely, to avoid complexity and
duplication.

> That way we have only one device (with one vnode) in the kernel
> that does all the work.

Well, yes, but I think that applies and is a requirement regardless
(otherwise they're not aliases at all, right? :)

> My reason for suggesting ordering (looking for aliases after we have foun=
d=20
> all the wedges) is to make life easier. I'm working with the idea that=20
> we will require sub-wedges to fit within a parent wedge.

This is sensible, for the idea of a primary name or something like the
"dmesg path" alluded to previously.

I'm nervous that someone, somewhere, will come up with a case where
the appropriate parent hierarchy isn't clear.  dsl had an example
recently with multiple 169 partitions and multiple nested extended mbr
partitions.  I'm not sure if it's an example of this problem, but it
certainly confused me.

> > This probably needs to be done in the wedge descriptor itself, with a
> > list of names each might take.  Or the names move entirely out of it,
> > and are built by devfs-mumble using references to a unique wedge id.
>=20
> Having aliases in the wedge info is fine. The problem I'm thinking/fussin=
g=20
> about is what happens if the wedge doesn't exist when we notice the alias.

Yeah. Which is why we may be better doing the allocation complexity,
to record what we noticed in one pass, and leave the presentation,
naming and aliases to the devfs pass.

(Pass in the sense both of run-time, and design-time :)

Perhaps in-kernel tools only create "primary names", and aliases are
created by userland tools (which may have to run before root is
mounted rw, if fstab compatibility needs aliases, like in your
examples.)

--
Dan.


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

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

iD8DBQFBYLFcEAVxvV4N66cRAt7mAKDH68hv2hJQUiTP5AKLG2I2qndcYgCgu1u2
llcca5tM2Xgm2v3VSvXUYmU=
=3eNu
-----END PGP SIGNATURE-----

--9C8JZALFROMdO0HE--