> 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