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

On Sun, Sep 23, 2007 at 01:54:37AM +0900, Hiroyuki Bessho wrote:
> At Tue, 18 Sep 2007 13:21:11 -0700,
> Bill Stouder-Studenmund wrote:
> >=20
> >=20
> > >   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.
> >=20
> > Why would we want to support this option? I don't see the benefit to=20
> > making something like the "nex" module.
>=20
>   I'm afraid this "nex" was not a good example for optional module
> name after `module' keyword.  I thought we'd better to allow users to
> change how to "group" the codes into modules. (Sorry that I can't
> think of a better English word than "group".  I mean which codes go to
> which module.)  I was afraid that whatever rules we define, users might
> want the other way.

Group is probably a good word. However I'm not sure why we want to support=
=20
this. Why will users care exactly what is in which module?

If we're really supporting modules, we also need a way (beyond the scope
of exactly what you're talking about here but rather directly enabled by
what you're talking about here) of loading the right modules. A way that a
daemon or startup tool can notice we need driver X loaded into the kernel.
For direct-attach busses (PCI), we can match the locators in user space to
get a candidate list, then let the modules in the kernel figure it out.
For indirect busses (ISA), we can load modules and see if they attach.

The upshot is I fail to see why users will care what code is in exactly=20
which module. Assuming the drivers the user wants are in there, what more=
=20
will be needed?

I also see a strong downside to permitting this customization. I think=20
that it will make modules more complicated to support at the project=20
level. Sure, for any one compile, it won't matter. But when someone asks=20
us for help on the list, variety in exactly what is in which module will=20
complicate our support on the lists. With a consistent set of modules, we=
=20
can more readily understand a situation a user is having a problem with.

As a specific example, with a consistent configuration of what's in what=20
module, a user can post the output of modstat, and we all understand=20
what's loaded. With a variety in what goes in exactly what module, we=20
would realy need the output of nm on the modules to tell what's what.

> > I think a good rule is:
> >=20
> > a) If nothing depends on the attribute, leave it out.
> >=20
> > b) If something hard-coded into the kernel depends on the attribute, bu=
ild=20
> > it into the kernel. Also mark it as present for whatever dependency sys=
tem=20
> > we come up with.
> >=20
> > 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.
> >=20
>=20
>   I'd say for c):
>=20
>   c) if one module depends on the attribute that is not in the
>   kernel, the attribute is compiled into the depending module.
>=20
>   d) if more than one modules depend on the attribute that is not in
>   the kernel, a module for the attribute is made. And note all the
>   dependencies.
>=20
>   I hope this will reduce the number of modules and dependencies in
> some cases.

Why do we care about the number of modules?

I dislike this suggestion for the reasons above. What exactly is in a=20
given module will depend on the kernel it was built for. That strikes me=20
as a support nightmare. :-)

I admit I am assuming we have one thing that hasn't been mentioned, which=
=20
is a way to automatically load dependencies before loading a module. So if=
=20
I ask to load module X, which depends on Y and Z, Y depends on Z and P and=
=20
Q, and Z depends on R and S, then R & S get loaded, P & Q & Z get loaded,=
=20
Y gets loaded, then X gets loaded.

But I don't think that's that hard to add once the other pieces are there.=
=20
And there's lots of prior art.

Thus I do not understand why we want to reduce the number of dependencies.

I also see a strong advantage of modules for our release process. Right=20
now we build a number of kernels as part of building a release. With all=20
the drivers in modules, a number of the differences between kernels reduce=
=20
to a different set of drivers. So we can build the modules once and reuse=
=20
them. Or build only a few key sets of modules and reuse them as much as we=
=20
can. :-)

Take care,

Bill

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFG9X9WWz+3JHUci9cRAhS1AKCKCWXG1euTYV9gK+JG/QheSoqDggCeP8dl
O+xLn3/08V3ptsW2gVDA1Ds=
=PhvB
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--