From owner-freebsd-small Sat Apr 22 13:57:21 2000 Delivered-To: freebsd-small@freebsd.org Received: from lepton.subatomix.com (okc-224-168.mmcable.com [24.94.224.168]) by hub.freebsd.org (Postfix) with ESMTP id A4DD337B644 for ; Sat, 22 Apr 2000 13:57:17 -0700 (PDT) (envelope-from jss@lepton.subatomix.com) Received: from localhost (jss@localhost) by lepton.subatomix.com (8.9.3/8.9.3) with ESMTP id QAA31897; Sat, 22 Apr 2000 16:00:16 -0500 (CDT) (envelope-from jss@lepton.subatomix.com) Date: Sat, 22 Apr 2000 16:00:15 -0500 (CDT) From: "Jeffrey S. Sharp" To: papowell@astart.com Cc: freebsd-small Subject: Re: [HEADS-UP] reviewers needed for repairs to PicoBSD - In-Reply-To: <200004211426.HAA19092@h4.private> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 21 Apr 2000 papowell@astart.com wrote: > > Use a 'config file' for options. See the /etc/rc.conf for an > example of how to do this. Have a set of defaults, and then > allow things to be overridden in the defaults file. What I'm working on is similar to that. I've got most everything centralized into a few configuration files. However, instead of going the defaults-and-override route, I've stolen an idea from OOP. I have a hierarchial tree of configurations (buildtypes, if you will) that is much like a class inheritance hierarchy in OOP. Each buildtype in the tree inherits configuration from its parent, and can override or add to that configuration. There is a single top-level buildtype (equivalent to Object in java or t in Lisp) that everything inherits from. You can do the defaults-and-override thing if you want by limiting your tree to depth 1. > Have flags that allow you to build images that have: > > a) MFS file system as part of the system image I hadn't planned on supporting that, but it probably wouldn't be that hard. > b) system image that asks for a floppy > that contains the MFS image > (needed for multiple floppy boots) That's just a specific thing you can do with your configuration. No special stuff is needed in the makefile or scripts to support that. > c) system image that asks for a FILE that > contains the MFS image > (great for debugging MFS stuff - you just remake > the MFS and retry. You can also use NFS and get > it remotely) Same as last comment. > d) 2Meg images that work with CDROMS - you do NOT > ask for MFS in this one. Same as last comment. > Modify the various configuration tools and make files so that > you can specify the location of stuff in a file - i.e. > > cmd -f from_this_file > > This allows you to put the configuration dependent things in the > config file and then you can have the entire tree separate. I'm not sure how that applies to the way I've got things set up. > Use configure to generate the various Makefiles, etc., so that > you can build your code in a separate location from the actual > source. Combining this with the configure thing allows you to > make/build multiple systems from the same image. Again, this might not apply well, but it's worth checking out. > Pay LOTS and LOTS and LOTS of attention to tracing what is going > on, diagnostics, Agreed. > tests for files missing, etc. Remember - > most of the users will NOT be experts, and even the experts > make mistakes. Big Mistakes. HORRIBLY embarassing mistakes. > Like copying the source for a file instead of the executable > and then spending a day wondering why it would not boot. This is a weak point in the design. By increasing flexibility, things have been made more generalized. The result is that more things have to be specified by the user, and there is a lot more room for error. When I get enough done so that I don't feel embarassed showing it to you all, and if it is accepted as a good thing, then this one area in which we will need to work. =============================== Jeffrey S. Sharp (XorAxAx) jss@subatomix.com -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS/IT/MU d-@ s-:+ a21 C++(++++) UBL+(+++$)> P L+(+++$)> E+> W++ N+(++) o? K? w++$> !O M(-) !V PS+ PE Y PGP- t+ 5 X+ R(+) tv+ b+ DI++(+++) G++ e> h--- r+++ y+++ ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message