Subject: Re: Heads-Up: support for device rescan and detach
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/15/2004 20:14:16
Content-Type: text/plain; charset=us-ascii
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----