Subject: Re: Drivers with interrupts as LKMs
To: Jeremy Gale <jgale.work@gmail.com>
From: Jachym Holecek <freza@liberouter.org>
List: tech-kern
Date: 01/21/2005 03:55:15
> Thanks for the help everyone. This is my first NetBSD driver so there
> are a lot of gaps in my knowledge. Please excuse my ignorance.

No problem. For a first driver, I'd really recommend doing it the static
way -- that's well documented, the interfaces are stable and it's easier.
Unless you have to do an LKM, of course.

> > This scheme is independent of whether you work with an LKM or a compiled-in
> > driver -- provided that the bus in question has a function to locate device
> > on the bus (such as pci_find_device(9)).
> 
> Do you mean the locators remain in the kernel config file even when
> using the driver as an LKM?

No, in that case the kernel contains no information about your driver
and you have to do everything manually. What I meant is that autoconf(9)
does not make any difference between static vs. LKM drivers. Sorry if
the wording was confusing.

> Do you avoid the driver from being statically compiled-in by just not
> including the source in the *.files?

The files* are used only to supply information when config(8) is run.
The kernel configuration file (${arch}/conf/${NAME}) decides what
will be compiled into the kernel. You disable a driver just by commenting
out relevant entry of ${arch}/conf/${NAME}.

In case of an LKM-only driver, you don't need to touch files* at all.

> I don't believe the bus does have such a function. There is a
> v2opb_search but that just seems to be part of the standard autoconf
> stuff. It fills in the OBP-specific attach args struct and then calls
> config_match/attach.
>
> I'm not too interested in doing this correctly; I just want an LKM for
> development. I'd be more than happy with the hack that Allen mentioned
> - hardcoding the base address and irq number - I just don't know how
> to do it.

Fill them into the attach args (you'll want to fill them anyway) and
have foo_attach() just believe what the parent (you, really) says.
Chances are you can "steal" most code from v2opb_search() -- but I
haven't seen Wasabi's code.

> I guess I eventually need to call config_attach. I can fake out most
> of the information but I still need things like pointers to the parent
> bus.

You can obtain parent's "struct device *" like this (from kern_drvctl.c):

===
        struct device *d;

	TAILQ_FOREACH(d, &alldevs, dv_list) {
		if (!strcmp("opb0", d->dv_xname))
			/* got him */
===

Alternatively, if you have more opb instances (and if it's possible for
any of them to be parent for your device), you could do something like
(not tested):

===
	struct device *d;
	int i;

	for (i = 0; i < opb_cd.cd_ndevs; i++)
		d = opb_cd.cd_devs[i];
		/* do something with d */
===

[And you're correct in that you need to call config_attach().]

	Regards,
		-- Jachym Holecek