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

I set the Reply-to to tech-kern, and added it to the distribution. Sorry=20
for the delay in responding.

 On Tue, Aug 24, 2004 at 10:55:25PM +0200, Matthias Drochner wrote:
>=20
> * New LKM type *
>=20
> There is a new LKM type "LM_DRV" which takes a list of "cfdriver",
> "cfattach" and "cfdata" each. The drivers are added to the system
> and all potential parent busses rescanned.
> On unloading, all devices belonging to "cfdata" of the module
> are detached.
> See the examples in src/sys/lkm/dev/pci and src/sys/lkm/dev/pcmcia.
>=20
> * User interface *
>=20
> There is a new (super)user tool drvctl(8) which allows to detach
> devices and rescan busses. See the manpage for details.
> It needs a "pseudo-device drvctl", and a "/dev/drvctl" node
> to work.

Cool.

> * Design issues *
>=20
> Things which could be argued about...
>=20
> - Detaching devices: Is it right to allow detaching devices
>   (ie calling config_detach() on it) from anywhere, and just
>   notify the parent? Another approach would be to allow only
>   the parent to detach a child.

How about for now we only permit having the parent do it? If we need to,=20
we can add a way to tell a bus to detach one of its children, and so we=20
thus can support anything doing the detach.

> - It an integer array powerful enough to express all kinds
>   of bus addresses? It makes certainly no sense to support
>   an addressing scheme at runtime which is more powerful than
>   the scheme used on bootup (the config(8) generated locators
>   array). "drvctl -r" exposes it to userland, that's why I'm
>   raising the question. (Actually, I can live well with the
>   "everything can be expressed as an integer" approach.)

I don't think so. While integers work fine for the busses we have now, I=20
think fibre channel and iSCSI really want strings. Well, I _know_ iSCSI=20
wants strings. :-)

I do agree that it makes no sense to support something more powerful than=
=20
what boot supports. However, since iSCSI and FC really want more than=20
numbers, we need to add string locator support. :-)

If it's easy to add string support now, please do it. If it's not, we can=
=20
wait.

> - Interrupts during probe and attach? Would be a hardship
>   to disable generally. DEC OSF/1 (or what it is called
>   currently) has a special flag for this.

No idea here.

> * Future *

[snip]

> - In some future: Support on-demand loading of drivers.
>   Open issues here:
>   - how to represent device id/revision information (which
>     is in "attach args" now) to userland. Bus independantly
>     as much as possible.

I'm not sure how possible this will be.

Take care,

Bill

--+xNpyl7Qekk2NvDX
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBSQUIWz+3JHUci9cRAnw8AJ4+HI+RnISHe/9zfX50rPfSwGVvFgCfTtAu
QhCutdhOm7lSsPlTXTVnjkA=
=yC+o
-----END PGP SIGNATURE-----

--+xNpyl7Qekk2NvDX--