-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 11, 2007, at 3:35 PM, Andrew Doran wrote:

quoted text
> 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  
>>> 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.
>
good
quoted text
> - 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.
quoted text
> - 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.

quoted text
> - 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:
>
also MAXUSERS I think.
quoted text
> - 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.

Regards
- -----------------------------------------
Adam Hamsik
jabber: haad@jabber.org
icq: 249727910

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)

iD8DBQFG5vSmlIxPgX3Go0MRApbdAJ9Zo50kk0BhatOpja7BTRjksWZPjQCgxQZo
1pVLnhfZ2TBk1uI2n1My/HY=
=6QXt
-----END PGP SIGNATURE-----