Subject: Re: union filesystem problems
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 05/12/1999 10:02:56
On 11 May 1999, Chris G. Demetriou wrote:
: > Yes; however, the QUOTA code is likely used by far more people than the
: > CCITT/ISO code. (I was meaning to ask why it wasn't in an alpha GENERIC.)
: Actually, I'm not convinced that QUOTA has ever been adequately tested
: on the alpha... 8-)
`See my web server. See my web server limit quota.' :)
: > Now ... yes, I agree that we should have a way of doing an "everything"
: > kernel different from a "support most things" kernel, but we need to
: > STANDARDIZE THE FORMAT of the bloody config files (can someone say pmax?).
: I only agree with this if the way you get there isn't by including
: N files from an MI place to get those options. People should be able
: to read config files and figure out what's going on without having to
: read N other files.
I agree. There should be NO `include' directives, unless we have a
commented-out set of `remove' options in every single GENERIC (...which
would be pointless, of course).
A possible situation would be a Make rule that used cpp, m4, or some other
preprocessor to input both the MD devices, busses, and options, and the MI
config files contaiing all MI devices on particular busses and MI options.
It would then produce includeless `everything' and `support most things'
kernel config files (which could be checked-in like syscall.h). The
template would then be very easy to customize, and be relatively consistent
: > Also, standardize what MI options go in the "support most things" kernel.
: I disagree.
: I'd argue that, despite the fact that, say, both adosfs and filecorefs
: are MI file systems, the amiga doesn't need filecorefs and the ARM
: doesn't need adosfs. 8-)
Very well; using a preprocessor as above, we could easily define arch
specifics for whether something is supported in the `support most things'
kernel (with the entry _always_ there, whether commented out or not).
-- Todd Vierling (Personal firstname.lastname@example.org; Bus. email@example.com)