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

On Sat, Feb 07, 2004 at 01:10:35AM +0100, Quentin Garnier wrote:
> Hi folks,
>=20
> First, please don't disregard this post just because it is about modules.
> By no mean I want to drop the current practice of having a monolithic
> kernel.  I would never compile with options LKM most of my systems.  But
> sometimes, modularity is useful.

I agree!

> The attached diff is only against config(8).  Its aim is to provide ways
> to compile modules out of the standard kernel compilation scheme.

[snip]

> The user will have several choices:
>=20
> Case 1, good'old GENERIC_LAPTOP:
>=20
> ex* at pci? device ? function ?
> ex* at cardbus? cardslot ?
>=20
> =3D=3D=3D> No module is created
>=20
> Case 2:
>=20
> module ex* at pci? device ? function ?
> module ex* at cardbus? cardslot ?
>=20
> =3D=3D=3D> 3 modules are created:  ex.ko, ex_pci.ko and ex_cardbus.ko.
>=20
> Case 3:
>=20
> module ex* at pci? device ? function ?
> ex* at cardbus? cardslot ?
>=20
> =3D=3D=3D> only one module is created, since attribute ex_cardbus is stat=
ic and
>      depends on attribute ex.  The module name is ex_pci.ko.

My concern is that by having multiple module options, we create a support=
=20
morass. If this implementation is the direction we all want to go, I'd=20
rather have it than nothing.

But I think we'd be better served if we came up with some standard way to
carve the kernel up into modules. Among other things, drivers that
depended on other subsystems could easily register a dependence on them. =
=20
I'm mainly thinking of audio drivers, but usb would probably fit, and I
bet there will be more with time.

We will need a standard set of modules to be able to really support=20
3rd-party modules. If I as a vendor can't be sure about how to tell users=
=20
what they need to use my driver, I'll find I have to support something=20
"different." Also, if I choose to modularize things differently, and=20
end-user will be irritated I want them to change. If I do things=20
differently from a different 3rd-party vendor, we end up with drivers that=
=20
can't be mutually loaded.

> Also, you can use 'modular define' to define modular attributes that are
> not directly linked to a device, such as 'ac97', 'aurateconv'...  Then
> those can be built as modules if whatever needs them is a module.
>=20
> It is also possible to include files for an attribute only if it is
> compiled as module.  This would be really useful since most of our devices
> drivers don't provide detach() function, which are usually required for a
> LKM to work properly (unless it is specifically made not-unloadable).=20
> detach() functions have little use in a monolithic kernel and it is
> perfectly understandable to leave them out.  Thus a way is provided to
> include ``modular'' files (using the 'modular' keyword as a flag at the
> same level as need-count and need-flag).
>=20
> config(8) then adds all the modules targets at the %MODULES token inside
> the template Makefile.  Makefile.kern.inc should define a few variable to
> compile the modules, but it is not yet the most important point.
>=20
> This patch certainly does not provide modularisation for NetBSD.  It
> merely makes it possible to do this a near future.  Of course, our current
> LKM implementation is not really adapted to modularisation: no
> dependencies (mmm, unloading in the wrong order), no in-kernel linker that
> would help with module classes and resource allocation, no way to easily
> add a device driver for a bus and have it rescanned (e.g., PCI), etc.  But
> this config(8) patch neither prevents nor restricts implementation of
> solutions for those issues.
>=20
> I'm posting this now because I feel I've worked on it long enough to have
> a clear idea of what it actually provides and what would be the needs for
> modularisation, but there's still some work to make it complete: for
> example, file-systems are treated as regular options, but get a different
> syntax so config(8) can know that at least one is compiled and barf if
> it's not the case.  Since the patch does not provide a way to declare
> modular options, it is not possible yet to compile module for
> file-systems.
>=20
> Comments?  Flames?

I appreciate that you're working on this. Please keep doing it!

As an aside, I think we can learn a lot from Linux here. From what I=20
understand, they did some very unpleasant things at first, and have=20
itterated; we should learn from their mistakes and successes. How do they=
=20
handle this?

Take care,

Bill

--dc+cDN39EJAMEtIO
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAJa4hWz+3JHUci9cRAvggAKCRaQOl8QNUeZtHo5hxMfPsm/i59gCfex+Y
IQCfBQcqzddUZL/uv3v9GuY=
=5hg6
-----END PGP SIGNATURE-----

--dc+cDN39EJAMEtIO--