Re: RFC: boot images config. file format

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Mon, Apr 12, 2010 at 11:54 PM, David Young <dyoung%pobox.com@localhost> 
wrote:
> 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

I know.  I've investigated "Miniaturize" project source the other day.

> 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" ?

In your example config file, "filesystem", "partition", "disk",
"tarroot", "copy" are related to disk/partition.  "syspkgs",
"exclude", "files", "pathes" are about filesystem content.  I think
these two should be put in separate files.  See distrib/.  They're
clearly separating media and contents (ramdisk).

> 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
>