Subject: Re: kernel config and modules
To: Andrew Doran <email@example.com>
From: Adam Hamsik <firstname.lastname@example.org>
Date: 09/11/2007 22:03:50
-----BEGIN PGP SIGNED MESSAGE-----
On Sep 11, 2007, at 3:35 PM, Andrew Doran wrote:
> On Tue, Sep 11, 2007 at 12:54:32PM +0100, Matthias Scheler wrote:
>> On Sat, Sep 08, 2007 at 03:33:17PM +0200, Joerg Sonnenberger wrote:
>>> My suggestion is that all MI drivers for PCI, Cardbus, USB and
>>> (devices, not necessarily controllers) are collected from i386 and
>>> amd64's GENERIC kernels and added to
>> I would prefer to have well working support for device driver modules
>> which get loaded on demand.
> Seconded, and I think that spending time enhancing 'config' further
> is a
> waste of time. What are the problems with LKMs? I can think of some:
> - LKMs need to be compiled to match the kernel, MULTIPROCESSOR and
> so on.
> I have been working on this, and expect that it won't be a
> problem any
> more in a couple of months time.
> - LKMs depend on kernel data structures which change often. Again I've
> been working on this one, e.g. the recent callout changes
> although there's
> a lot of work to be done on this.
list of problematic data structures/apis would be useful.
> - The kernel needs to be able to load modules itself, and that
> means an
> in-kernel linker.
Can we use FreeBSD one? Or we have to write our own.
> - The autoconfiguration framework isn't suited to loading device
> The drivers have to do some quite odd things in order to find a
> to drive and get attached.
> - Mechanisms to prevent in-use modules from being unloaded are
> For example, a syscall module can be unloaded while its syscall is
> in use.
> What other problems are there?
> On a slight tangent I also think that many of the configuration
> files have
> become abominable because we have been abusing the config system.
> That leads
> to code that's hard to maintain and a system that's more difficult
> to use.
> I'm guilty of that as much as anyone else. Broadly speaking the
> options I
> can see fit into one or more of the following categories, with some
> I took from the i386 configs:
> - describes an optional subsystem or behaviour (DIAGNOSTIC)
> - should force a module to be compiled into the kernel (COMPAT_LINUX)
also MAXUSERS I think.
> - microptimizaton with no benefit (I386_CPU)
> - saves a few bytes (WSDISPLAY_COMPAT_PCVT)
> - forces user to handle a condition that the code should (TIMER_FREQ)
> - should be a runtime tunable (SHMMAXPGS)
> - has runtime tunable, remains for sentimental reasons (GATEWAY)
> - should be a device driver (VIA_PADLOCK)
> - too fine grained (COMPAT_09, COMPAT_10, COMPAT_11, ...)
> I know that it takes time and effort to change things and
> undoubtedly I have
> offended someone with the above list, but that's not what I want to
> do. My
> point is that the machines NetBSD runs on now and NetBSD itself are
> a lot
> more complicated than they were 14 years ago, and static configuration
> doesn't really cut it, either for the developers or the users.
> So my suggestion is that we need to think more about adding compile
> options, not just go ahead and do it because that's the way it has
> been done, and that we should work to neutralise many of the
> existing ones.
Proud NetBSD user.
We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----