Subject: Re: LINT'ing the kernel
To: Rui Paulo <rpaulo@fnop.net>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-kern
Date: 04/23/2006 11:46:05
Rui Paulo <rpaulo@fnop.net> writes:

> Thor Lancelot Simon <tls@rek.tjls.com> writes:
>
>> On Sun, Apr 23, 2006 at 12:46:50PM +0100, Rui Paulo wrote:
>>> Christos Zoulas <christos@netbsd.org> writes:
>>> 
>>> > Module Name:	src
>>> > Committed By:	christos
>>> > Date:		Sat Apr 22 23:56:39 UTC 2006
>>> >
>>> > Modified Files:
>>> > 	src/sys/dev/isa: if_ntwoc_isa.c
>>> >
>>> > Log Message:
>>> > Make this compile again. We really need an ALL kernel.
>>> 
>>> FreeBSD has a LINT kernel config file that solves this problem.
>>> Why don't we try to do the same ?
>>
>> We used GENERIC for this purpose until people started mysteriously not
>> including some things in GENERIC. *Shrug*
>
> Well, true. But there's always the problem of not having a GENERIC
> kernel for all ports. I would be happy if we could create a GENERIC.in
> under sys/conf/ and then use that for all the ports we have (if
> there's a problem with some special port, we now have the 'no' thing
> in config(1)).
>
> Anyway, the FreeBSD LINT kernel is not for common usage but only for
> test-compile from what I understand.

GENERIC has a different purpose.  Right now it doesn't have IPSEC due
to performance issues, and it doesn't have ACPI, stf, faith, or pf.
This is fine - GENERIC is intended to be suitable for almost everyone
(except those who are memory contrained or want to do something
unusual).  While perhaps more should be enabled in GENERIC, it won't
be reasonable to enable everything.

So a LINT kernel that includes GENERIC and then has the not-enabled
bits would be good (and useful documentation of things that can be
added - they could perhaps then be removed from GENERIC).

I think factoring out MI options is a separate issue.  This is hard
because what's harmless unused code on a modern i386 is
memory-stealing bloat on a 64MB sparc.


-- 
        Greg Troxel <gdt@ir.bbn.com>