Subject: Re: Request for comments: let config(1) generate LKMs
To: Juan RP <juan@xtrarom.org>
From: Hiroyuki Bessho <bsh@grotto.jp>
List: tech-toolchain
Date: 09/14/2007 00:21:45
Thank you for the comment.

At Thu, 13 Sep 2007 13:17:55 +0200,
Juan RP wrote:
> 
> On Thu, 13 Sep 2007 18:55:32 +0900 (JST)
> Hiroyuki Bessho <bsh@NetBSD.org> wrote:
> 
> 
> The only problem is how to build different LKMs for the same driver,
> but with different locators (I/O port, IRQ, etc).
> 
> On drivers where a different I/O port can be used, the driver itself might
> have to probe them before the final attach (something like nsclpcsio(4)
> currently does), to avoid multiple different modules, e.g:
> 
> 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 we can allow users to say

module       ne0	at isa? port 0x280 irq 9
module "nex" ne1	at isa? port 0x290 irq 10
module "nex" ne2	at isa? port 0x300 irq 11

  In this case, module ne.o has ne and ne_isa driver codes and a
device instance ne0. Module nex.o will have only config(9) glue staff
to probe port 0x290 and 0x300 and attach ne1 and/or ne2 because ne and
ne_isa related codes are in module ne.o.  I'm not 100% sure this works
yet, but I guess that allowing users to specify module name for
devices will provide good way for some configuration.  And if it
works, config(1) can detect that module nex.o depends on module ne.o
and can submit some useful information.

  And I know there can be some issues with

ne*	at mca? slot ?
module	"ne_isa"    ne0 at isa? port 0x280 irq 9
module  "ne_pcmcia" ne* at pcmcia? function ?

  In this case, ne driver is in the kernel, so ne_isa.o has ne_isa
attachment codes, and ne_pcmcia.o has ne_pcmcia codes.  The problem is
that both ne_isa and ne_pcmcia require the attribute rtl80x9.  If we
compile rtl80x9 related codes into both ne_isa and ne_pcmcia, we can't
load both modules at the same time.  If we compile rtl80x9 only into
ne_isa.o, ne_pcmcia.o depends on ne_isa.o, which doesn't look very
nice.  The solution I can think of for now is

  a) allow users to say
      module rtl80x9
     to tell independent module for the attribute rtl80x9 and don't
     compile it into ne_isa.o or ne_pcmcia.o.  Without "module
      rtl80x9", rtl80x9 related codes is compiled into ne_isa.o.
  b) config(1) implicitly generate rtl80x9.o.

  I believe if we go further we'll encounter many cases to solve like
this, and we need to define good rules how `module' keyword works in
config(5).


--
bsh.