tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: boot images config. file format
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
>
Home |
Main Index |
Thread Index |
Old Index