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. >
_______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
