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

On Thu, Oct 27, 2005 at 07:27:46PM -0700, Jason Thorpe wrote:
>=20
> On Oct 27, 2005, at 6:14 PM, Bill Studenmund wrote:
>=20
> >I can think of two other reasons for doing the maping trick. One is =20
> >I see
> >all of this as an extension/embellishment of kernel autoconfig =20
> >locators.
> >So the userland devfs config is an extension of the kernel's wiring =20
> >down.
> >Since we wire down "sd3" and such now, I suggest we continue to do =20
> >so. I
> >also think this will make it all make more sense to folks as we
> >transitition.
>=20
> We *CAN* wire "sd3" and such down now.  But it makes less and less =20
> sense in today's world, what with all of the hot-plug busses out =20
> there these days.
>=20
> We can certainly make symlinks in the devfs form the "location name" =20
> to the "unit name", e.g.:
>=20
> 	/dev/sd3 -> /dev/sd.wwn.52004567BA64678D

I'd rather not.

I realize it'd be a rather easy step, but we then essentially have two=20
device names running around. I'd like to avoid that if possible.

> (Note the lack of a letter after the name ... part of my EVIL PLAN, =20
> MUAHAHAHA!)

Oh, I know. And I'm right there with you. :-)

> In my world, wedges would create old-style partition-letter names in =20
> the devfs for partition formats where that makes sense, e.g. for BSD =20
> disklabel wedges:
>=20
> 	/dev/sd3a -> /dev/dk/sd3a
> 	/dev/dk/sd3a -> /dev/dk5
>=20
> etc.
>=20
> For EFI wedges, you would not have these compatibility links, but =20
> instead would simply have:
>=20
> 	/dev/dk/nbsd4.0root -> /dev/dk0
>=20
> etc.  "nbsd4.0root" being the name for that partition in the EFI =20
> label.  For EFI, name collisions would be handled by falling back to =20
> the string representation of the partition's UUID.

I think that's fine.

> >Second, I think it's easier to keep track of "sd0", "sd3","sd62", and
> >"sd89" than "sd.wwn.52004567BA64678D", "sd.wwn.52002E004D3E218F",
> >"sd.wwn.52000F4C31D7AA70" and so on. I think it will be a lot =20
> >easier to
> >understand log messages and to configure other parts of the system =20
> >if we
> >have to deal with the shorter names. All of the characters in both =20
> >names
> >are significant, but most of the wwn characters carry little human
> >relevance. So I'd rather our admins focus effort on dealing with =20
> >devices
> >and what they are doing rather than huge device names.
> >
> >I would rather not have log messages like:
> >
> >sd.wwn.52004567BA64678D(umass0:0:0:0): command aborted, data =3D 00 =20
> >00 00 00
> >04 04 00 00 00 00
>=20
> I'm not suggesting reporting errors that way.  I'd keep current unit =20
> names for errors, or possibly have them reported up at the wedges =20
> layer if wedges exist for the device.

As above, my main concern with this bit was that if we have multiple names=
=20
for the same device then we still have a measure of confusion. ;-)

Take care,

Bill

--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDYm9mWz+3JHUci9cRAj0TAJ48iKYcGOt1s8DawM8+R60aKxXHFACfVx+9
kjr/A2iDyu0mCQvbp9GzhHs=
=3wHd
-----END PGP SIGNATURE-----

--1yeeQ81UyVL57Vl7--