--pgp-sign-Multipart_Wed_May_24_11:12:24_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 23 May 2006 21:22:42 -0500,
Jonathan A. Kollasch wrote:
>=20
> On Tue, May 23, 2006 at 07:57:30PM -0400, Thor Lancelot Simon wrote:
> > So, it's hard to understand why this is so upsetting to you, when one
> > considers that it would require a 10-second edit to /etc/fstab to fix.
>=20
> So true.

It's not really that hard to understand at all actually, especially when
you consider that most, if not all, of the non-BSD world is used to
dealing with what they perceive as more predictable device naming
schemes.

"Obviously" the BSD way is more flexible in the most academic manner,
but for most production uses it's infinitely more logical to expect
device names to stay static so long as the hardware has any chance of
being probed in the same logical order every time (by the same software,
of course).

> But, yes, like Thor said, it's most often simpler (at least if your not
> doing this constantly) to just edit fstab.  (Or just ignore fstab and mou=
nt
> manually.)

Well, perhaps if the goal was to both move the current boot drive to
another hardware attachment, _and_ then boot from it again.

However in the original post I believe the issue was with a secondary
drive taking over the place of the primary in the kernel's device space,
thus suddenly creating what appeared to be a completely hosed system.
This cannot happen if the existing root device keeps it name regardless
of what and where any additional disks are attached.

> That being said, I don't think autoconf(9) is quite flexible enough to
> do enumeration like Linux does.  But then again, it is flexible enough
> to allow manual enumeration.  Whatever.

I think the real problem is that autoconf(9) will skip over non-existant
things, esp. the likes of disks, so that when something steps in to fill
their place then the device space changes dynamically.

Especially for attachable devices like disks they should always be
located in the device space by some representation of their hardware
addressable location, regardless of how many addresses before them are
unused.

The only sane alternative, at least for disks, and perhaps it's even far
more sane than what I suggest (as it is definitely far more flexible) is
Steve Bellovin's suggestion to use volume labels.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_May_24_11:12:24_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: dA6vWRFhZsEavpYtFdeTGT2YQVwtId8V

iQA/AwUBRHR4BmJ7XxTCWceFEQLglACgyb+YO4dHkecbJC4G41KGDCeZPzkAnA6K
ofN1aBVl6TfcOVmiU8078gsV
=Xb8T
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_May_24_11:12:24_2006-1--