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

On Thu, Sep 27, 2007 at 04:42:55PM +0900, Hiroyuki Bessho wrote:
> Bill Stouder-Studenmund wrote:
> >
> >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 mor=
e=20
> >will be needed?
> > =20
>  OK, I gave up to convince you to think allowing optional module names=20
> is a very useful feature, as I couldn't think
> of stronger examples.  Anyway it's optional and if we make good enough=20
> rules to satisfy all users,  no one will use it.

I'm still concerned. If it's an optional feature no one uses, it can rot.=
=20
Or maintaining it will add overhead to other changes that doesn't have=20
much value.

> >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.
> > =20
>  I don't think  you need  to worry about such cases.  If I implement=20
> the feature (It is implemented for now,
> but I'm not sure I'll keep it), it is just for users who want a special=
=20
> tweak (like me), and I don't expect many
> users will use it and get confused and ask you to help on the list.

Ok.

> >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. :-)
> > =20

>  I'm afraid you cannot be completely free from your nightmare :-)  =20
> There always be some cases where
> LKMs from one config file doesn't work with a kernel from the other=20
> config file.  `options'  can affect
> both LKMs and kernel, for example.

Please look closer at our LKM framework. It currently remembers=20
"important" options, and will refuse to load a module that was built for a=
=20
different set of "important" options. So we have this protection now. :-)

One thing we can do over time is add version IDs to individual modules. If=
=20
we have a standard set of modules with standard IDs, we can tag an LKM as=
=20
depending on specific versions. Actually, my hope is in the long run we=20
can get the linker to help w/ this.

The idea is that when we change a subsystem, in addition to bumping the=20
overall kernel version, we bump the version ID of that subsystem and=20
everything that depends on it.

Now all of a sudden, we have a definite way of determining if a module can=
=20
load. If it was compiled for the same set of options and all the loaded=20
modules have the desired versions, then the module can load safely. :-)

Note: this is a feature we can work on after this work.

> >I admit I am assuming we have one thing that hasn't been mentioned, whic=
h=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 a=
nd=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.
> > =20
>  I  believe we are basically on the same assumption here.  I think the=20
> best place to put module dependencies is
> LKM .o file using ELF sections.  Modload(8) can be extended to read=20
> those sections to find required
> modules.  But you seem to assume one thing that I don't;
>=20
>   LKMs are independent with kernels, and you can load any LKMs to the=20
> kernel built from the differenct config file.

Kinda.

I agree that we want LKMs to be independent of the kernel they were built=
=20
for. I like this idea.

In practice, however, until we have the versioning I babbled about above,=
=20
it'll be hard to tell if an LKM is compatabile or not w/ the kernel. Yes,=
=20
we can check compile options. But other than checking the overall kernel=20
version, it's hard to be sure if an LKM will actually work. So what I've=20
seen Linux do is you just have a directory of LKMs to go with the kernel.

>  To support it, we'll need changes to kernel to provide some means to=20
> know which attributes are in the running kernel.
> I feel it's easier to tell users to use LKMs from the same config file=20
> with the kernel, at least for the first step.

Agreed.

>  For load-time efficiency.  Assume you have module A which depends on=20
> module B, and no other
> module needs module B.  If you always load module B when you need=20
> module A,  why don't you
> link them together into one module?  I always prefer doing  as many=20
> things as possible  in  compile time
> to  consuming  CPU cycles  in  run-time.
>=20
>  And also I guess kernel memory consumption is smaller with one=20
> combined module than with multiple
> modules with same functionality.
>=20
>  But you made me realize that  it is a kind of optimization rather than=
=20
> a principal.  I think I should make it
> an option to config(1).  For your healthy sleep,  users may be=20
> discouraged to use the option  :-)

I think a better way to do it would be to provide a way to make custom=20
LKMs. It's a semantic difference, but it:

1) is something we'd need anyway so that someone can release binary-only=20
LKMs.

2) encourages anyone doing this to create his or her own name for the=20
module, which completely short-circuits my objection above. My concern is=
=20
radically-different LKMs having the same name due to "grouping" or other=20
options. But if you come up w/ your own LKMs with their own names, no=20
problem.

Take care,

Bill

--6BvahUXLYAruDZOj
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFG/AhiWz+3JHUci9cRAkqdAJsGdov+CYjyiaWHMQ2Z1/QNTPeGlQCghWSF
uov98lZ5hVFlDKBfhFwscjk=
=xGQ6
-----END PGP SIGNATURE-----

--6BvahUXLYAruDZOj--