Date: Mon, 24 Feb 2003 07:32:46 +0100 From: phk@phk.freebsd.dk To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <8287.1046068366@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 23 Feb 2003 22:05:17 PST." <20030224060517.GA9757@dhcp53.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I am violently in favour of having compilable LINT kernels on all platforms, but I do not like the path we are heading down splitting NOTES into per feature files: It does not solve the fundamental problem and it simply does not scale in the long term. Part of the fundamental problem is that a single LINT kernel, even per architecture is not able to test both branches of an #ifdef/#else/#endif construct. Generating a LINT1 and LINT2 per architecture would give us much better code coverage. Going down the path of NOTES.this and NOTES.that does not help us solve this problem becuase it does not capture the information we need to know, but it does take us down a path of total fragmentation into umpteen files which nobody will have any kind of overview off how is stuck together in a few months time. There are two ways to do this right: Either one large or strictly per feature information files which capture the knowledge today captured in GENERIC/NOTES, conf/options* and conf/files* and in addition contains the bits of information we need to generate correct LINT files per architecture. I would personally prefer that it be strictly per-feature files since huge files tend to become unmanagable as well. I am not going to raise a bikeshed about the format of said files, I'll just leave my bucket of blue paint here for those who will do the bikeshed. Summary: 1. Strictly per feature files, not "adhoc groupings" 2. Much more expressive format than NOTES needed. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8287.1046068366>