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

On Fri, Oct 28, 2005 at 01:00:00AM +0200, Pavel Cahyna wrote:
> On Thu, Oct 27, 2005 at 03:49:42PM -0700, Bill Studenmund wrote:
> > The "userland" in my text above would be the devfs setup code (script a=
nd=20
>=20
> Ah, I haven't understood that.
>=20
> > data) that runs at boot to set devfs up as wanted. That code would use=
=20
> > locators to figure out that "sd3" really should be "sd6" and so forth. =
And=20
> > it would make changes to devfs such that it was so.
> >=20
> > Everything else in userland isn't going to change. cdrecord is still go=
ing=20
> > to open /dev/rcd0d.
>=20
> What if the devfs implementation decides that "cd0" should be "cd1"? Now,
> configuration files for such programs (most important example is
> fsck, mount and /etc/fstab if as you say "sd3" moves to "sd6", but also
> cdrdao, cdrecord etc.) will have to be changed.

A direct answer to your question is that the devfs implementation won't=20
"decide" to move things around of its own volition. It will be adhering to=
=20
guidelines and configurations the administrator already had set up (on=20
previous boots).

The devfs seen after boot reflects the hardware initially found by the
system and modifications made by subsequent administrative actions.

"sd3" moving to "sd6" would only happen because the administrator did
something in the past to indicate that it should be "sd6" and not "sd3". =
=20
This could either be that it was "sd6" in the past and the admin decided
to wire it down, or it could be that it was something else (say "sd2") and
the admin wired it down (as wwn whatever or maybe even as scsibus X target
Y) and then did something to make it "sd6". "mv" may well suffice for the
renaming, but I don't have the locator-wiring interface complete in my
head.

Thus "sd6" is what the administrator wants to be "sd6".

So other config files shouldn't have to change because they would have=20
been set up when this hypothetical disk already was wired down as sd6.

More to the point, the whole idea of what I want to do with locators and
such is expressly so that config files DON'T have to change. Regardless of
how things probe (and probing can get intersting in a SAN), "sd6" points
to whatever it's supposed to point to and nothing else.

An alternative reason to move something is that sd0 through sd5 were wired=
=20
in the devfs config and whatever now is "sd6" matches none of them. Thus=20
it is moved out of the way of sd0 through sd5. But even this is a reaction=
=20
to what the administrator asked for, thus config files shouldn't have to=20
change.

Note: exactly what happens to unknown devices is a policy decision that
would be in the devfs startup config. I can see a use for other choices,
like "don't let them appear until the admin does something explicit." But
we digress.

Does that make things clearer?

Take care,

Bill

--6BvahUXLYAruDZOj
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDYXPnWz+3JHUci9cRAtzXAJ0XSUDXQps/eyMfTbEgvTqoVyaIoACglWdo
HOaUt64miw7llwC8EeXgdhQ=
=UBi6
-----END PGP SIGNATURE-----

--6BvahUXLYAruDZOj--