Date: Thu, 05 Nov 1998 18:41:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: Mike Smith <mike@smith.net.au>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, sos@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/modules/syscons saver.h ... Message-ID: <199811051041.SAA05859@spinner.netplex.com.au> In-Reply-To: Your message of "Thu, 05 Nov 1998 09:06:58 GMT." <Pine.BSF.4.01.9811050904451.19324-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote:
> On Wed, 4 Nov 1998, Mike Smith wrote:
[..]
> > I'm still very much of the opinion that stuff shouldn't have to be
> > mentioned in the config file at all; that all that the config file
> > specifies is what gets aggregated into the kernel object.
>
> I agree about that. The description of what is attached to what is
> correct though.
I've been thinking.. It shouldn't be all that hard to have "modules"
built in the same place as the kernel, but I can't think of a good
variation of syntax for config(8).
Consider all those opt_*.h files. It would be nice to be able to use the
ones from the corresponding kernel rather than having to second guess
things.
I mentioned this to Mike some time ago and his comment was equivalent to
'aargh!'.
The way I see it, we need:
- something that resembles config syntax where practical to minimize
culture shock.
- NOT having to specify (redundant) configuration heirarchies - this is
coded within the source, there is no need to duplicate it in the config
file.
- make it module aware; specify what goes into the static kernel, what
goes into modules, and what goes into both.
- modules and kernel could/would be serialized so that kernel/module
mismatches could be detected.
- it should NOT build in the source tree but in an obj dir.
I originally thought about having isa and static configuration
information, but I now think that is a job for the boot loader and
userconfig (also in the boot loader) to pass in the configuration. ISA
config could/should be based from a text file pulled in by the loader.
All that we'd be left with was effectively a 'packing list' of what to
build and with what options and in what form (kernel, module etc).
In fact, I wonder if it might be possible to go from the other direction
and specify what components get build and how to package them; ie
something like this:
# GENERIC
machine "i386"
cpu "I386_CPU"
cpu "I486_CPU"
cpu "I586_CPU"
cpu "I686_CPU"
maxusers 32
options COMPAT_43
options SCSI_DELAY=3000
options FAILSAFE
kernel {
ident GENERIC
proto inet
vfs ffs
vfs mfs
vfs nfs
vfs procfs
bus rootbus
bus isa
bus eisa
bus pci
device fdc
disk fd # dynamic
tape ft # dyanmic
device wdc0
device wdc1
disk wd0 at wdc0 unit 0 # hardwired
disk wd # dynamic
disk wcd
disk wfd
bus scbus
disk da # dynamic
device ncr
device ahc
...
device de
device tun32 # specifically 32 units
};
module nfs; # use a default list of components
module mystuff {
vfs ext2fs
emul linux
};
module coda { # presumably this would also be defaulted.
vfs coda
device codadev
};
module default; #build all default modules
Obviously there would be a list of files that build "vfs ext2fs" etc, and
a default list of known modules and default contents for convenience. For
example, "module nfs;" would have an implied default set of contents. It
would be functionally equivalent to:
module nfs {
vfs nfs;
}
"module all" would build all known modules. this probably wouldn't be
attractive since you'd almost be building enough modules to make a runtime
LINT kernel.
The kernel "knows" internally that fd devices attach to the fdc bus, etc.
At least, it will under Doug's system when it gets implemented. You would
not need to specifically specify that 'fd0 hangs off fdc0'. However,
there are legitimate instances where hardwiring of units makes sense.
The other key thing is that the packaging is pretty much freeform, as long
as you obey the basic rules. The backing system rules file might specify
inter-module dependencies or prerequisites for linking - for example
"device codadev" depends on "vfs coda". If you built them into seperate
modules, the module containing codadev would automatically get a
dependency on the module containing the coda vfs, etc. Doing a 'kldload
codadev' would automatically pull in the coda module etc.
Obviously I've just invented the syntax without much thought, but you get
the idea.
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811051041.SAA05859>