Date: Mon, 24 Feb 2003 17:32:10 -0800 From: "Eugene M. Kim" <ab@astralblue.net> To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030225013210.GA21089@purple.the-7.net> References: <8287.1046068366@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I have this creepy feeling that I may be just blindly retracking a
well-explored path, but how about adopting and extending the model we
already use for our ports tree, i.e.:
o Each part of the kernel is reorganized into a module which:
- Provides one or more features,
- (Optionally) requires a list of other features, and
- (Optionally) refuses to compile or load when some features are
already present.
o This `feature description' resides in a separate file along with the
module source files. Feature files shall follow a consistent naming
convention (*.feature for example).
o The kernel configurator scans the kernel source tree for these feature
files to construct the global feature database. This eliminates the
need for manual maintenance of a monolithic feature database file.
o A feature is uniquely identified by a string.
o Each module has at least one globally unique feature identifier. The
kernel configurator shall generate an error if it finds, after
scanning the source tree, multiple modules that declares the same
unique provider.
o Multiple modules can provide the same feature, but only one of those
modules can be compiled in and/or loaded at the same time. For
example, features "ule-scheduler" and "4bsd-scheduler" could both
provide the "scheduler" feature, and features "i386-machine" and
"alpha-machine" could both provide the "machine" feature.
o A module can declare itself as a default feature provider. For
example, "4bsd-scheduler" can be the default provider of "scheduler"
feature. The kernel configurator shall generate an error if it finds
multiple default providers for the same feature.
o There are two kinds of dependencies; strong versus weak.
o Strong dependency prevents the module from being compiled/loaded if
the dependency can't be met (by compiling in or loading the required
module).
o Weak dependency permits the module to be compiled/loaded even if the
dependency can't be met.
o A `metafeature' is a feature that contains no actual code but a list
of other required features (analogous to metaports). For example,
"snd" would require (through weak dependencies) on "snd-pcm" and bunch
of other soundcard driver modules.
These are as much as I can think up now. Anyhow, the goal here is to
come up with a framework that can handle not just platform dependencies
but also intermodule dependencies.
Thanks,
Eugene
----- Original Message -----
From: <phk@phk.freebsd.dk>
To: <freebsd-arch@FreeBSD.ORG>
Sent: Sunday, February 23, 2003 10:32 PM
Subject: Re: [RFC] splitting of conf/NOTES
>
> 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
>
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?20030225013210.GA21089>