Subject: Re: Request for comments: let config(1) generate LKMs
To: Bill Stouder-Studenmund <firstname.lastname@example.org>
From: Jachym Holecek <freza@NetBSD.org>
Date: 09/20/2007 16:21:28
# Bill Stouder-Studenmund 2007-09-18:
> > > [...]
> > >
> > > module it0 at isa? port 0x290
> > > module it1 at isa? port 0xc00
> > > module it2 at isa? port 0xd00
> > >
> > > What do you think? what's the best option to fix all this crap?
> > In the case above, device instances it go to module it.o, along
> > with codes related to it and it_isa. When it.o is loaded, 0x290 is
> > probed and it0 is attached if it exists, and same for 0xc00 and 0xd00.
> I think a better solution is to conceptualize locators as independent of
> the code in the module.
> We code them into the kernel now both because we've always done that and
> because it's the easiest way to do it in a monolithic blob.
> For LKMs, however, I think it's better to have the code and have a plist
> that includes the locators.
Yes, the locators (well, a cfdata_t actually) can be loaded via drvctl(4)
when you make a request to attach new device(s). But this is not that
easy right now -- given just driver's code (which boils down to a cfattach
conceptually), you have no way to tell what two attributes does it
glue together. This information is stored in cfdata_t, whose primary
purpose is to describe potential device instances. What I think would
be best would be to explicitely state the two attributes being glued
together in the cfattach directly, but that's rather intrusive of a