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

On Sat, Oct 02, 2004 at 12:23:59PM +1000, Daniel Carosone wrote:
> On Fri, Oct 01, 2004 at 05:16:21PM -0700, Bill Studenmund wrote:
> > Also, I was thinking that we could use aliases to handle cases where we=
=20
> > had mapped an msdos or Linux partition into a NetBSD disklabel in an MB=
R.=20
> > While we wouldn't have added wedges for these (as they aren't within th=
e=20
> > NetBSD MBR wedge), we may still want something like "wd0j" to map to th=
em.
> >=20
> > My tentative thought is to add all the wedges, then try to add aliases.=
 =20
> > That way, regardless of MBR order, when we create aliases, the original=
=20
> > wedge has already been added.
>=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.

My thought is that one name would be special, so aliases are more like
symlinks. That way we have only one device (with one vnode) in the kernel
that does all the work.

> If they're real aliases, then each label-parser can simply create the
> wedge (if those sectors are not already mapped by a wedge) and then
> add its name to it.  Once again, ordering doesn't matter.

My reason for suggesting ordering (looking for aliases after we have found=
=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. Like in an MBR=20
Disklabel scheme, the disklabel wedges are in the NetBSD MBR partition.=20
Anything outside the NetBSD MBR partition doesn't get permitted.

So thus my wd0i, which matches an NTFS partition in the MBR label, would=20
not be created. If the NetBSD disklabel gets processed before that MBR=20
partition, when we go to look at wd0i, there will not be a wedge for it to=
=20
alias. So we either have to: 1) look for aliases later (my thought), 2)=20
permit the NetBSD disklabel-reading code to generate a wedge outside of=20
its containing wedge (seems really bad, since then what's the point of a=20
containing wedge), or 3) figure out a way to generate "alias requests"=20
that for instance the NetBSD disklabel-reading code would create when it=20
saw wd0i was outside the NetBSD MBR partition, and that some other code=20
would line up with the Windows partition later. #1 and #3 do the same=20
thing, but trade computation complexity (looking at the NetBSD disklabel=20
twice) for allocation simplicity (not allocating an "alias request").

> 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.

Having aliases in the wedge info is fine. The problem I'm thinking/fussing=
=20
about is what happens if the wedge doesn't exist when we notice the alias.

Take care,

Bill

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

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

iD8DBQFBYKvrWz+3JHUci9cRAhA/AKCOYooU+Es8GShyiTbvt3I8EW74vwCfZlI5
XahZqk391qtsYnid3/6aOZI=
=D1Hh
-----END PGP SIGNATURE-----

--dTy3Mrz/UPE2dbVg--