Date: Fri, 21 Apr 2000 07:26:43 -0700 (PDT) From: papowell@astart.com To: jss@subatomix.com, papowell@astart.com Cc: freebsd-small@FreeBSD.ORG Subject: Re: [HEADS-UP] reviewers needed for repairs to PicoBSD - Message-ID: <200004211426.HAA19092@h4.private>
next in thread | raw e-mail | index | archive | help
> From jss@lepton.subatomix.com Wed Apr 19 17:49:41 2000
> Date: Wed, 19 Apr 2000 19:52:44 -0500 (CDT)
> From: "Jeffrey S. Sharp" <jss@subatomix.com>
> To: papowell@astart.com
> cc: freebsd-small@FreeBSD.ORG
> Subject: Re: [HEADS-UP] reviewers needed for repairs to PicoBSD -
>
> On Wed, 19 Apr 2000 papowell@astart.com wrote:
> >
> > ... 'make supported build' ...
> >
> > Looks like the answer is no for now.
> >
>
> I'm also working on a make-based build system. I pitched FreeBSD to my
> boss for use as an embedded OS, and I succeeded. (Yay!) So, I'm working
> on what I call the TinyBSD Development Kit (remember -- imitation is
> flattery). I have been given copyright on the stuff I write, and will of
> course will release it to the public under a BSD-style license.
>
> While my system does not use configure, it does have the following
> interesting (IMHO) properties:
>
> * A hierarchial source tree, of arbitrary depth, that lets child
> buildtypes inherit/override configuration from their parents.
>
> * Support for multiple disks.
>
> * Arbitrary slicing/partitioning of disks.
>
> * Arbitrary number/type of filesystems, mappable to multiple
> partitions.
>
> * Crunched binaries or shared libraries.
>
> * kgzipped kernels, gzipped kernels, or uncompressed kernels
>
> * (possibly) build to image or to device
>
> While originally intended for building not-quite-pico-sized images (flash
> disks), it looks like it will be general enough to handle all sorts of
> sizes, including floppies.
>
> Completion level is 20%. I will hopefully finish no more than two weeks
> from now.
>
> Any thoughts or comments are greatly appreciated.
>
> ===============================
> Jeffrey S. Sharp (XorAxAx)
> jss@subatomix.com
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.
Have flags that allow you to build images that have:
a) MFS file system as part of the system image
b) system image that asks for a floppy
that contains the MFS image
(needed for multiple floppy boots)
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)
d) 2Meg images that work with CDROMS - you do NOT
ask for MFS in this one.
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.
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.
You can then do 'diffs' or whatever to make sure that things
got done right.
Pay LOTS and LOTS and LOTS of attention to tracing what is going
on, diagnostics, 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.
Patrick ("Error messages? Isn't 'system fault - core dump'
good enough for you?") Powell
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004211426.HAA19092>