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

On Wed, Sep 28, 2005 at 09:18:17AM +0200, Alan Barrett wrote:
> On Sat, 24 Sep 2005, Quentin Garnier wrote:
> > While trying to find ways of extending the 'no <dev> at <attach>' syntax
> > of config, I came upon the issue of orphans.
>   [...]
> > The reason why I'm not committing this right away is because I want to
> > gather opinions on how to do the next level.
>=20
> I think that the following behaviour would be most useful:
>=20
>    When checking for orphans, consider all possible wildcard matches as
>    acceptable.  This includes:
>=20
>       parent0 at wherever
>       child0 at parent?
>       child* at parent?
>=20
>       parent* at wherever
>       child0 at parent?
>       child* at parent?
>=20
>       parent* at wherever
>       child0 at parent0
>       child* at parent1

The last one isn't really acceptable, as instances of the parent device
may suddenly be probed in another order, thus changing the identity of
child0 and its siblings.

This happened in the past:  when Manuel Bouyer made ATA devices probing
happen after interrupts are enabled, order of cd(4) devices changed on
my station (I had one on scsi, the other on atapi).  Of course, cd(4)
devices don't have children, but you get the idea.

What I mean is that as soon as you start being specific about your
hardware configuration, you'd better be explicit.  If you reference two
explicit instances of a device through their children, you should have
two explicit instances of the device.

It's not hard to check for a wildcarded parent device, though.

>    If you try to attach a device to a parent, and the parent hasn't been
>    mentioned at all, then warn about the child being orphaned.  Or perhaps
>    make it an error rather than a warning.
>=20
>    If the parent has been mentioned, but has also been cancelled via some
>    variant of the "no" syntax, then silently do the right thing.  This
>    includes recursion, so
>=20
>       pci* at mainbus?
>       uhci* at pci?
>       usb* at uhci?
>       uhub* at usb?
>       uhub* at uhub?
>       umass* at uhub?
>       wd* at umass?
>       no usb
>=20
>    will just silently act like
>=20
>       pci* at mainbus?
>       uhci* at pci?

This makes me think I might have been wrong since the beginning.
Instances declarations don't have to be ordered, why should instances
negations be?  Wouldn't it make sense to have 'no usb' first and still
get the same result?

I'll see how I can keep track of negated instances meanwhile.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--2Z2K0IlrPCVsbNpk
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBQzpWD9goQloHrPnoAQKW2wf/Q7aAdY3OfFqj3AK5Gd8YaHzxbwndx0MO
OBbvAFY5nzahOg2RVOy/iEJkBlOpKUNi2xjT2R9MbJP+brA9bboSpabvPk+LhLXi
hpLoBPN+NczmRHvHU+gDgX5E3OaNgG5QTU9e93UhQ2qRuYGU6FPOLtSyxpLkzm3U
rccFC6HbZ6sbYQrYH64m1iHN/EdJxgu6IeW/evGny4m0pwLpO0/sH2e9T0HXLi0B
VdqSVQvVDBHdV7lkH8OBRKnH90IIez+NMi7C6j5zxCaUHQngYk1rZznNmJaAn/0k
7iGLetBpWwf24eQlbgK42UxaAaHEfnqdRb6gcZzrl78SVtCwj0GjwQ==
=JWgz
-----END PGP SIGNATURE-----

--2Z2K0IlrPCVsbNpk--