--Hf61M2y+wYpnELGG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 14, 2007 at 12:21:45AM +0900, Hiroyuki Bessho wrote:
> Thank you for the comment.
>=20
> At Thu, 13 Sep 2007 13:17:55 +0200,
> Juan RP wrote:
> >=20
> > On Thu, 13 Sep 2007 18:55:32 +0900 (JST)
> > Hiroyuki Bessho <bsh@NetBSD.org> wrote:
> >=20
> >=20
> > The only problem is how to build different LKMs for the same driver,
> > but with different locators (I/O port, IRQ, etc).
> >=20
> > On drivers where a different I/O port can be used, the driver itself mi=
ght
> > have to probe them before the final attach (something like nsclpcsio(4)
> > currently does), to avoid multiple different modules, e.g:
> >=20
> > module it0 	at isa? port 0x290
> > module it1 	at isa? port 0xc00
> > module it2 	at isa? port 0xd00
> >=20
> > What do you think? what's the best option to fix all this crap?
> >=20
>=20
>   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=20
the code in the module. We code them into the kernel now both because=20
we've always done that and because it's the easiest way to do it in a=20
monolithic blob.

For LKMs, however, I think it's better to have the code and have a plist=20
that includes the locators.

>   I think we can allow users to say
>=20
> 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
>=20
>   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.

Why would we want to support this option? I don't see the benefit to=20
making something like the "nex" module.

>   And I know there can be some issues with
>=20
> ne*	at mca? slot ?
> module	"ne_isa"    ne0 at isa? port 0x280 irq 9
> module  "ne_pcmcia" ne* at pcmcia? function ?
>=20
>   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
>=20
>   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.
>=20
>   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).

Option (b). Even if it means some config changes to standard defintion=20
files.

Right now, users don't have to include anything to make ne @ isa or ne @
pcmcia work. No special commands regarding rtl80x9.o It happens as a
result of including things that need it.

I see no reason why adding module support should change that, and a lot of=
=20
reasons why it shouldn't. :-)

I think a good rule is:

a) If nothing depends on the attribute, leave it out.

b) If something hard-coded into the kernel depends on the attribute, build=
=20
it into the kernel. Also mark it as present for whatever dependency system=
=20
we come up with.

c) if modules depend on the attribute and nothing hard coded into the=20
kernel does (i.e. we aren't also in case (b)), make a module. And note all=
=20
the dependencies.

Take care,

Bill

--Hf61M2y+wYpnELGG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG8DM3Wz+3JHUci9cRAtPUAJ4o8QZlbJA60ITjOrUHK7FY2SGSYACfUrDz
m+V6PEMXkLJUWE183EkAZKs=
=Gr0a
-----END PGP SIGNATURE-----

--Hf61M2y+wYpnELGG--