It seems like the build would be cleaner if we had two lists of files to add to the lar and added them in two steps.
lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ... lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
The unfortunate thing with the nocompress:file:lar_path style is that it makes it difficult to add support for other flags, unless you specify a flag ordering. For example imagine if you wanted to add a flag specifying to add the file as close to the end as possible, etc.
The reason I was interested is I still think the cleanest way is to allow repacking of lar files (i.e., no intermediate format), but I don't see a good way to add that option with the current usage model for lar.
Myles
On Thu, Feb 21, 2008 at 8:16 AM, Myles Watson mylesgw@gmail.com wrote:
It seems like the build would be cleaner if we had two lists of files to add to the lar and added them in two steps.
lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ... lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
The unfortunate thing with the nocompress:file:lar_path style is that it makes it difficult to add support for other flags, unless you specify a flag ordering. For example imagine if you wanted to add a flag specifying to add the file as close to the end as possible, etc.
The reason I was interested is I still think the cleanest way is to allow repacking of lar files (i.e., no intermediate format), but I don't see a good way to add that option with the current usage model for lar.
that idea looks really good to me, if you can make it work. I like it anyway. The per-file flags are somewhat hard to parse.
I think we might want a pass for 'lar z' as well.
I hope this does not cause as much argument as the other ideas :-)
Anyway, want to drop a patch on us?
ron
From: ron minnich [mailto:rminnich@gmail.com] I think we might want a pass for 'lar z' as well.
What would that be?
I hope this does not cause as much argument as the other ideas :-)
I don't seem to be able to tell that when I suggest things, but I hope not too.
Anyway, want to drop a patch on us?
Sure, as soon as I understand the third pass.
Myles
On Thu, Feb 21, 2008 at 8:48 AM, Myles Watson mylesgw@gmail.com wrote:
From: ron minnich [mailto:rminnich@gmail.com]
I think we might want a pass for 'lar z' as well.
What would that be?
just say: lar z build/bios.bin
it zero-fills the lar and makes booting dramatically faster.
BTW: another way to greatly speed up booting: cat /dev/ttyS0
instead of minicom :-(
This on a T23, but still ...
ron
From: ron minnich [mailto:rminnich@gmail.com] On Thu, Feb 21, 2008 at 8:48 AM, Myles Watson mylesgw@gmail.com wrote:
From: ron minnich [mailto:rminnich@gmail.com]
I think we might want a pass for 'lar z' as well.
What would that be?
just say: lar z build/bios.bin
it zero-fills the lar and makes booting dramatically faster.
Wouldn't this break buildrom if someone had that enabled automatically, then tried to add a payload?
Maybe zero-filled segments of lar files could be resized?
I think to do this right it deserves a separate patch.
Myles
On 21.02.2008 17:16, Myles Watson wrote:
It seems like the build would be cleaner if we had two lists of files to add to the lar and added them in two steps.
lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ... lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
The unfortunate thing with the nocompress:file:lar_path style is that it makes it difficult to add support for other flags, unless you specify a flag ordering. For example imagine if you wanted to add a flag specifying to add the file as close to the end as possible, etc.
I have a patch which changes lar syntax to something more reasonable and standard. The new syntax is option:option:option:fileondisk=fileinarchive That solves the delimiter problem quite nicely.
Opinions?
The reason I was interested is I still think the cleanest way is to allow repacking of lar files (i.e., no intermediate format), but I don't see a good way to add that option with the current usage model for lar.
--exporttolar and --importfromlar?
Regards, Carl-Daniel
Per-file options are really a rare thing in Unix world. Not in all places, they're very common in some OSes. I am unsure if the per-file thing is going to be so unfamiliar as to confuse people.
Also, ':' is a pathname seperator (or used to be) in MAC OS ...
ron
-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Thursday, February 21, 2008 4:47 PM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] v3 build process and lar flags
On 21.02.2008 17:16, Myles Watson wrote:
It seems like the build would be cleaner if we had two lists of files to
add
to the lar and added them in two steps.
lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ... lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
The unfortunate thing with the nocompress:file:lar_path style is that it makes it difficult to add support for other flags, unless you specify a
flag
ordering. For example imagine if you wanted to add a flag specifying to
add
the file as close to the end as possible, etc.
I have a patch which changes lar syntax to something more reasonable and standard. The new syntax is option:option:option:fileondisk=fileinarchive That solves the delimiter problem quite nicely.
Opinions?
The per-file options were fragile because there was only support for one at the beginning of the option, and to add another you'd either have to specify an ordering, or check all possible orderings.
The reason I was interested is I still think the cleanest way is to
allow
repacking of lar files (i.e., no intermediate format), but I don't see a good way to add that option with the current usage model for lar.
--exporttolar and --importfromlar?
Sorry I missed this before. Here are a few comments:
1. There's no need to export if you can import into a new lar.
2. I didn't mean that I couldn't think of a name for the option. I just meant that since we were using per-file options there would probably need to be a per-file option for which lar to search for a file you wanted to add. If we remove the per-file option and expect people to use multiple runs of lar, it makes it much easier to add something like:
lar -c newlar.rom -L oldlar.rom normal payload/segment0
Another problem I was having was whether I should search the lar first, then the filesystem. It's a lot easier to just look in one place, and fail if it's not found. It also makes it less surprising to users.
Myles
Regards, Carl-Daniel
On 23.02.2008 00:28, Myles Watson wrote:
Carl-Daniel Hailfinger wrote:
On 21.02.2008 17:16, Myles Watson wrote:
It seems like the build would be cleaner if we had two lists of files to add
to the lar and added them in two steps.
lar -c coreboot.rom $(NOCOMPRESS_FILES) -s $(ROM_SIZE) ... lar -a coreboot.rom $(COMPRESS_FLAG) $(COMPRESSIBLE_FILES)
The unfortunate thing with the nocompress:file:lar_path style is that it makes it difficult to add support for other flags, unless you specify a flag
ordering. For example imagine if you wanted to add a flag specifying to add
the file as close to the end as possible, etc.
I have a patch which changes lar syntax to something more reasonable and standard. The new syntax is option:option:option:fileondisk=fileinarchive That solves the delimiter problem quite nicely.
Opinions?
The per-file options were fragile because there was only support for one at the beginning of the option, and to add another you'd either have to specify an ordering, or check all possible orderings.
My patch solved that problem.
The reason I was interested is I still think the cleanest way is to allow
repacking of lar files (i.e., no intermediate format), but I don't see a good way to add that option with the current usage model for lar.
--exporttolar and --importfromlar?
Sorry I missed this before. Here are a few comments:
There's no need to export if you can import into a new lar.
I didn't mean that I couldn't think of a name for the option. I just
meant that since we were using per-file options there would probably need to be a per-file option for which lar to search for a file you wanted to add. If we remove the per-file option and expect people to use multiple runs of lar, it makes it much easier to add something like:
lar -c newlar.rom -L oldlar.rom normal payload/segment0
Another problem I was having was whether I should search the lar first, then the filesystem. It's a lot easier to just look in one place, and fail if it's not found. It also makes it less surprising to users.
Indeed.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Myles Watson -
ron minnich