On Tue, Sep 11, 2007 at 12:54:32PM +0100, Matthias Scheler wrote:
quoted text
> 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 PCMCIA
> > (devices, not necessarily controllers) are collected from i386 and
> > amd64's GENERIC kernels and added to
> > src/sys/conf/std.{pci,cardbus,usb,pcmcia}.
> 
> 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.

- The kernel needs to be able to load modules itself, and that means an
  in-kernel linker.

- The autoconfiguration framework isn't suited to loading device drivers.
  The drivers have to do some quite odd things in order to find a device
  to drive and get attached.

- Mechanisms to prevent in-use modules from being unloaded are missing.
  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 examples
I took from the i386 configs:

valid:

- describes an optional subsystem or behaviour (DIAGNOSTIC)
- should force a module to be compiled into the kernel (COMPAT_LINUX)

invalid:
 
- 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 time
options, not just go ahead and do it because that's the way it has always
been done, and that we should work to neutralise many of the existing ones.

Thanks,
Andrew