We we get around to adding blobs to a LAR from within buildROM, we have an interesting situation, best described with an example.
For Geode we need a VSA blob to operate correctly. BuildROM wants to download this blob from a website, and insert it into the the LAR with a well known name, lets use 'vsa' for giggles.
This patch allows you to specify an arbitrary filename as well as a pathname for files in create & add mode in the following manner:
[flags]:[filename]:[pathname]
So instead of copying the VSA binary into a local directory and renaming it 'vsa' before adding it o a LAR, instead we use something like this:
./lar -a my.lar ../sources/vsa.bin:vsa
This puts the blob into the LAR, and names it 'vsa'.
(the -a functionality is coming in the next patch).
Jordan
[PATCH][LAR] Allow user to specify pathnames for create and add
Add another field to the filename specified for create and add operations to specify the intended pathname for the blob.
Signed-off-by: Jordan Crouse jordan.crouse@amd.com Index: LinuxBIOSv3/util/lar/stream.c =================================================================== --- LinuxBIOSv3.orig/util/lar/stream.c 2007-07-11 11:48:23.000000000 -0600 +++ LinuxBIOSv3/util/lar/stream.c 2007-07-11 11:48:51.000000000 -0600 @@ -436,6 +436,8 @@ int lar_add_file(struct lar *lar, char *name) { char *filename, *ptr, *temp; + char *pathname; + enum compalgo thisalgo; struct lar_header *header; int offset, ret, fd, hlen; @@ -456,6 +458,18 @@ thisalgo = none; }
+ pathname = strchr(filename, ':'); + + if (pathname != NULL) { + *pathname = '\0'; + pathname++; + + if (!strlen(pathname)) { + err("Invalid pathname specified.\n"); + return -1; + } + } + if (filename[0] == '.' && filename[1] == '/') filename += 2;
@@ -508,7 +522,7 @@ munmap(ptr, s.st_size); close(fd);
- pathlen = strlen(filename) + 1 > MAX_PATHLEN ? MAX_PATHLEN : strlen(filename) + 1; + pathlen = strlen(pathname) + 1 > MAX_PATHLEN ? MAX_PATHLEN : strlen(pathname) + 1;
/* Figure out how big our header will be */ hlen = sizeof(struct lar_header) + pathlen; @@ -535,7 +549,7 @@
/* Copy the path name */ strncpy((char *) (lar->map + offset + sizeof(struct lar_header)), - filename, pathlen - 1); + pathname, pathlen - 1);
/* Copy in the data */ memcpy(lar->map + (offset + hlen), temp, complen); Index: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3.orig/util/lar/lib.c 2007-07-11 11:40:29.000000000 -0600 +++ LinuxBIOSv3/util/lar/lib.c 2007-07-11 11:49:00.000000000 -0600 @@ -148,16 +148,29 @@ { struct stat filestat; int ret = -1; - const char *realname; + char *realname; + char *c; + + realname = strdup(name); + + if (realname == NULL) { + fprintf(stderr, "Out of memory.\n"); + exit(1); + }
- realname = name; if (strstr(name, "nocompress:") == name) { - realname = name + 11; + realname += 11; }
+ c = strchr(realname, ':'); + + if (c != NULL) + *c = '\0'; + /* printf("... add_files %s\n", name); */ if (stat(realname, &filestat) == -1) { fprintf(stderr, "Error getting file attributes of %s\n", name); + free(realname); return -1; }
@@ -202,6 +215,7 @@ ret = 0; }
+ free(realname); return ret; }
Acked-by: Ronald G. Minnich rminnnich@gmail.com
On 7/11/07, Jordan Crouse jordan.crouse@amd.com wrote:
We we get around to adding blobs to a LAR from within buildROM, we have an interesting situation, best described with an example.
For Geode we need a VSA blob to operate correctly. BuildROM wants to download this blob from a website, and insert it into the the LAR with a well known name, lets use 'vsa' for giggles.
This patch allows you to specify an arbitrary filename as well as a pathname for files in create & add mode in the following manner:
So instead of copying the VSA binary into a local directory and renaming it 'vsa' before adding it o a LAR, instead we use something like this:
./lar -a my.lar ../sources/vsa.bin:vsa
This puts the blob into the LAR, and names it 'vsa'.
(the -a functionality is coming in the next patch).
Jordan
[PATCH][LAR] Allow user to specify pathnames for create and add
Add another field to the filename specified for create and add operations to specify the intended pathname for the blob.
Signed-off-by: Jordan Crouse jordan.crouse@amd.com Index: LinuxBIOSv3/util/lar/stream.c =================================================================== --- LinuxBIOSv3.orig/util/lar/stream.c 2007-07-11 11:48:23.000000000 -0600 +++ LinuxBIOSv3/util/lar/stream.c 2007-07-11 11:48:51.000000000 -0600 @@ -436,6 +436,8 @@ int lar_add_file(struct lar *lar, char *name) { char *filename, *ptr, *temp;
char *pathname;enum compalgo thisalgo; struct lar_header *header; int offset, ret, fd, hlen;@@ -456,6 +458,18 @@ thisalgo = none; }
pathname = strchr(filename, ':');if (pathname != NULL) {*pathname = '\0';pathname++;if (!strlen(pathname)) {err("Invalid pathname specified.\n");return -1;}}if (filename[0] == '.' && filename[1] == '/') filename += 2;@@ -508,7 +522,7 @@ munmap(ptr, s.st_size); close(fd);
pathlen = strlen(filename) + 1 > MAX_PATHLEN ? MAX_PATHLEN : strlen(filename) + 1;
pathlen = strlen(pathname) + 1 > MAX_PATHLEN ? MAX_PATHLEN : strlen(pathname) + 1; /* Figure out how big our header will be */ hlen = sizeof(struct lar_header) + pathlen;@@ -535,7 +549,7 @@
/* Copy the path name */ strncpy((char *) (lar->map + offset + sizeof(struct lar_header)),
filename, pathlen - 1);
pathname, pathlen - 1); /* Copy in the data */ memcpy(lar->map + (offset + hlen), temp, complen);Index: LinuxBIOSv3/util/lar/lib.c
--- LinuxBIOSv3.orig/util/lar/lib.c 2007-07-11 11:40:29.000000000 -0600 +++ LinuxBIOSv3/util/lar/lib.c 2007-07-11 11:49:00.000000000 -0600 @@ -148,16 +148,29 @@ { struct stat filestat; int ret = -1;
const char *realname;
char *realname;char *c;realname = strdup(name);if (realname == NULL) {fprintf(stderr, "Out of memory.\n");exit(1);}
realname = name; if (strstr(name, "nocompress:") == name) {realname = name + 11;
realname += 11; }c = strchr(realname, ':');if (c != NULL)*c = '\0';/* printf("... add_files %s\n", name); */ if (stat(realname, &filestat) == -1) { fprintf(stderr, "Error getting file attributes of %s\n", name);free(realname); return -1; }@@ -202,6 +215,7 @@ ret = 0; }
free(realname); return ret;}
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Wed, Jul 11, 2007 at 12:22:27PM -0600, Jordan Crouse wrote:
This patch allows you to specify an arbitrary filename as well as a pathname for files in create & add mode in the following manner:
Another great idea!
./lar -a my.lar ../sources/vsa.bin:vsa
I don't like having all this information (algo too) in-band with the filename.. I don't know a nice way to do it for when adding many files at once though. :\ I was thinking about a "lar script" that would say what goes where with what algo but it would be nice to not have to go there.
//Peter
On 12/07/07 01:36 +0200, Peter Stuge wrote:
On Wed, Jul 11, 2007 at 12:22:27PM -0600, Jordan Crouse wrote:
This patch allows you to specify an arbitrary filename as well as a pathname for files in create & add mode in the following manner:
Another great idea!
./lar -a my.lar ../sources/vsa.bin:vsa
I don't like having all this information (algo too) in-band with the filename.. I don't know a nice way to do it for when adding many files at once though. :\ I was thinking about a "lar script" that would say what goes where with what algo but it would be nice to not have to go there.
I was definately thinking about going that direction. In fact, I talked to Stefan about it at OLS. It wouldn't really have to be a script - Stefan has been thinking about creating a MANIFEST file when we extract the LAR that lists the blobs and where they are located - we could use the exact same format on the input side too:
-------------------------------------------- # MANIFEST # Filename pathname algorithm /root/my.payload normal/payload lzma ... bootblock bootblock - ---------------------------------------------
(As an example). This might actually be better for buildROM - then each target that builds a blob for the LAR would just echo the line into this file - thats probably cleaner then something ugly like
LAR_BLOBS += $(SOURCE_DIR)/$(GEODE_VSA):vsa
Which is what I'm doing now.
Jordan
On Wed, Jul 11, 2007 at 05:50:10PM -0600, Jordan Crouse wrote:
"lar script"
I was definately thinking about going that direction. In fact, I talked to Stefan about it at OLS. It wouldn't really have to be a script - Stefan has been thinking about creating a MANIFEST file when we extract the LAR that lists the blobs and where they are located - we could use the exact same format on the input side too:
I say just print it to stdout on extract. The filenames (on disk) will obviously always be homogenous on extract, but lar could have a -C option like tar to relocate from cwd. Pathnames are always straight from the larball.
# MANIFEST # Filename pathname algorithm /root/my.payload normal/payload lzma ... bootblock bootblock -
(As an example).
Yeah, I guess the GMTA principle says this is the way to go.
The one-line-per-file is slightly problematic in that it makes whitespace instead of : be reserved in filenames. :\ (Because the filename needs to be there twice it's not possible to just put the algo first and use the rest as filename.)
And I prefer "none" over "-" for no compression. Bikeshed though.
This might actually be better for buildROM - then each target that builds a blob for the LAR would just echo the line into this file - thats probably cleaner then something ugly like
LAR_BLOBS += $(SOURCE_DIR)/$(GEODE_VSA):vsa
Which is what I'm doing now.
Sure, the manifest is certainly nice for scriptability. I'd like it to be readable from stdin too. Maybe you can use some clever here documents in buildrom then.
//Peter
* Jordan Crouse jordan.crouse@amd.com [070712 01:50]:
# MANIFEST # Filename pathname algorithm /root/my.payload normal/payload lzma ... bootblock bootblock -
Do we really need to distinguish between filename and pathname? I don't understand the difference here, unless it's a copy operation instead of an archive. Back when we invented lar, we thought about making all matches via the filename. So I think pathname is an idea to go away from that fixed mapping again...?
I'd rather define file types rather than pathnames?
Or is the pathname such a filetype, and the name is just ambiguous?
I like that you can add/exchange a file via the command line, and one needs to specify all the information in the manifest on the command line, too. So we should think about what goes in there.
Stefan
On 12/07/07 13:10 +0200, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [070712 01:50]:
# MANIFEST # Filename pathname algorithm /root/my.payload normal/payload lzma ... bootblock bootblock -
Do we really need to distinguish between filename and pathname? I don't understand the difference here, unless it's a copy operation instead of an archive. Back when we invented lar, we thought about making all matches via the filename. So I think pathname is an idea to go away from that fixed mapping again...?
Actually - pathname *is* the fixed mapping. The filename:pathname scheme is to bridge the gap between a real world filename (like say, filo.elf), and the mapping within the LAR that LinuxBIOS understands (normal/payload).
I'd rather define file types rather than pathnames?
Or is the pathname such a filetype, and the name is just ambiguous?
Sure - we can use the term filetype if you want. Pathname is a little bit more descriptive, since the LAR can technically hold arbitrary blobs of data - what ever the loader needs ('vsa') comes to mind.
But its just a term - I would be happy to use filetype if thats a better way to think about these things.
Jordan
* Peter Stuge peter@stuge.se [070712 01:36]:
./lar -a my.lar ../sources/vsa.bin:vsa
I don't like having all this information (algo too) in-band with the filename.. I don't know a nice way to do it for when adding many files at once though. :\ I was thinking about a "lar script" that would say what goes where with what algo but it would be nice to not have to go there.
Yes, a lar script ("MANIFEST" ?) would be what we want here...
-
Jordan Crouse -
Peter Stuge -
ron minnich -
Stefan Reinauer