Re: RFC: boot images config. file format

[David Young <dyoung%pobox.com@localhost>]

On Mon, Apr 12, 2010 at 11:05:26PM +0900, Masao Uebayashi wrote:
> a) Be aware of sysinst
> 
> As you wrote some time ago, off-line installation and on-line
> installation (sysinst) should be considered together.  Share
> infrastructure as much as possible.  What are the internal interfaces?

Yes, they should be considered together before new projects are begun.
This is not a new project.  A lot of the code is written.  I am not
going to try to solve both problems at a stroke, that project is too
big.

> b) Filesystem content vs. disks/partitions
> 
> I don't like these two things are mixed in single configuration file.
> Please separate them clearly.

Please, be more specific.  What don't you like, and what does it mean to
"separate them clearly" ?

The idea of this file format is to tell how to construct a bootable
application image---e.g., a firewall, a router, or a live CD---by
listing the image's parts and telling how to assemble them.

> c) Multiple disks, raid, LVM, ...
> 
> We should be able to handle multiple disks.  For example 1GB USB disk
> as system (/) and multiple HDDs as data.  A small NOR FlashROM as /
> and a larger NAND FlashROM as /usr, etc.

Out of scope.

> Hopefully the config file can be capable of raidframe and LVM too.

I hope it can, someday.  For now it is out of scope.

> d) Configuration vs. customization
> 
> I want to clearly separate configuration and "customization" (my
> terminology; these are not clearly defined in NetBSD!)
> 
> Editing /etc/rc.conf and removing part of /bin/* (base-util-bin) are
> very different; the former is a standard configuration.  The latter is
> beyond the standard configuration; we don't expect *usual* users to do
> that.  Thus I'd call it "customization", meaning user makes an
> unexpected local modification.

Well of course you're going to customize an application image.  The
image's configuration file sets the expectation of what is and is not
present on the image.

> If local changes are only to add files in some unused filesystem
> namespace (typically /usr/local or /home/*, etc), we could think of
> these changes as not really unexpected.  These changes are less likely
> to harm the default behavior.  I think we should define the standard
> interface for users to extend freely (which is what I intended by
> "extsrc").
> 
> I think the customization part of the proposed statements (exclude,
> files, patches, trim, build, ...) is too flexible.  Again, I want to
> clearly differenciate these local changes.  If an image has nothing
> locally changed, but only install some syspkgs, it's a perfectly
> normal NetBSD system.

With the possible exception of the 'patches' statement, which I have
found problematic in practice, the customization part is just flexible
enough to build application images.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933