Well, if anyone wants it, here is my stab at adding variable expansion to
the filename field. It doesn't work with relative tftp uris because I don't
care and I don't feel like reworking how that buf array is alloced. Do with
it as you will or will not. The declaration of expand_command probably
should be in a header instead of just dumped in, but this is how I got what
I wanted with adding three lines of code and changing one. I'm sure even
with that I made enough dubious moves to warrant a rethought, but its
something...
On Thu, May 20, 2010 at 2:44 PM, Miller, Shao
<[email protected]>wrote:
> I'm forwarding your request on to the gPXE Developers' mailing-list, since
> I think the folks there would be well-suited to voice opinions on your
> request. - Shao
>
> ________________________________________
> From: Jarrod Johnson [mailto:[email protected]]
> Sent: Thursday, May 20, 2010 14:41
> To: Miller, Shao
> Cc: [email protected]
> Subject: Re: FW: [gPXE] environment variable expansion in 'filename'?
>
> Would you mind a patch to add the expand_command to autoboot.c?
> On Thu, May 20, 2010 at 2:31 PM, Miller, Shao <[email protected]>
> wrote:
> Hey again Jarrod,
>
> I'm forwarding this on to the gPXE list.
>
> gPXE actually does support conditionals right now, though they're extremely
> icky. See "crazy scripting library" thread[1] or "fall-back filename"
> thread[2]. However, there doesn't seem to be much interest, much time, much
> support, much discussion, or some combination thereof for a couple of
> [relatively] recent proposals to enhance gPXE's scripting/CLI system[3].
>
> - Shao Miller
>
> [1] http://etherboot.org/pipermail/gpxe/2010-March/000646.html
> [2] http://etherboot.org/pipermail/gpxe/2010-April/000846.html
> [3] http://etherboot.org/pipermail/gpxe-devel/2010-March/000102.html
>
> ________________________________________
> From: Jarrod Johnson [mailto:[email protected]]
> Sent: Thursday, May 20, 2010 14:19
> To: Miller, Shao
> Subject: Re: [gPXE] environment variable expansion in 'filename'?
>
> So, currently, that's how it goes and I used fixed-address declarations so
> looking up the 'best' next-server isn't too hard. Without fixed-address,
> things start getting tricky based on what I'm trying to do. While still
> possible for me to externally coordinate what network the booting device
> will land in, it would be much simpler for my purposes to inherit
> 'next-server' from the 'subnet {}' portion of dhcp, but I need to specify
> per-node paths at a host declaration level. Things get hypothetically
> trickier if netboot with DHCPv6 comes into life following the rule in DHCPv6
> where DUID is constant regardless of interface when I'm dealing with
> multihomed devices. There I might have a single host declaration that has
> to describe two network relationships, but that's all theoretical.
>
> On a related note, is it horribly objectionable or a bad idea for
> expand_command from exec.c to be called from boot_next_server_and_filename
> from autoboot.c? Failing that I'll contemplate an embedded script, but lack
> of conditionals is gPXE scripting could prove to be a touchy thing.
>
>
>
diff -urN gpxe-1.0.0/src/core/exec.c gpxe-1.0.0-expandfilename/src/core/exec.c
--- gpxe-1.0.0/src/core/exec.c 2010-02-02 11:12:44.000000000 -0500
+++ gpxe-1.0.0-expandfilename/src/core/exec.c 2010-05-20 21:28:43.000000000 -0400
@@ -94,7 +94,7 @@
* The expanded command line is allocated with malloc() and the caller
* must eventually free() it.
*/
-static char * expand_command ( const char *command ) {
+char * expand_command ( const char *command ) {
char *expcmd;
char *start;
char *end;
diff -urN gpxe-1.0.0/src/usr/autoboot.c gpxe-1.0.0-expandfilename/src/usr/autoboot.c
--- gpxe-1.0.0/src/usr/autoboot.c 2010-05-20 20:56:32.000000000 -0400
+++ gpxe-1.0.0-expandfilename/src/usr/autoboot.c 2010-05-20 21:31:49.000000000 -0400
@@ -32,6 +32,7 @@
#include <usr/dhcpmgmt.h>
#include <usr/imgmgmt.h>
#include <usr/autoboot.h>
+char * expand_command ( const char *command );
/** @file
*
@@ -85,6 +86,8 @@
uri_encode ( filename, buf + strlen ( buf ),
sizeof ( buf ) - strlen ( buf ), URI_PATH );
filename = buf;
+ } else { /* only support variable expansion in absolute paths to avoid stepping on buf size */
+ filename = expand_command(filename);
}
image = alloc_image();
_______________________________________________
gPXE-devel mailing list
[email protected]
http://etherboot.org/mailman/listinfo/gpxe-devel
