Subject: Re: Heads-Up: support for device rescan and detach
To: Matthias Drochner <>
From: Bill Studenmund <>
List: current-users
Date: 09/15/2004 20:14:16
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:
> * New LKM type *
> 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.
> * User interface *
> 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.


> * Design issues *
> Things which could be argued about...
> - 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=
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=

> - 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 *


> - 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,


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

Version: GnuPG v1.2.3 (NetBSD)