# 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[012] 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.

Wholeheartedly agreed.

> 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
change obviously...

	-- Jachym