[syslinux] pxechn.c32: Status

[Gene Cumm]

On Sun, Nov 7, 2010 at 10:27, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> --On Sunday, November 07, 2010 08:12:22 AM -0500 Gene Cumm
> <gene.cumm at gmail.com> wrote:
>
>> Now that pxechain.com can work (with my patch to core/pxelinux.asm)
>
> Thanks for tracking this down; somehow I don't think I'd have found the time
> to do so anytime soon.
>
>> I'm looking at being able to either call the PXE API with opcode 0073h
>> (PXENV_RESTART_TFTP) or do it all ourselves.
>
> As you know, PXECHAIN currently uses the PXENV_RESTART_HTTP method.  I've
> partially implemented the "do it ourselves" method, asking PXELINUX to load
> and run the new NBP, but I have a few bugs I haven't had time to track down.
>  So, I don't see any reason why a COM32 version shouldn't be able to use
> that approach; in fact, I expected it to be more reliable as well as having
> a better chance of regaining control if something goes wrong.  I also
> considered an approach of TFTP'ing the new NBP and then asking PXELINUX to
> run it, but that seemed unnecessarily complex.

I think that the COM32 can have more flexibility and reliability until
attempting to shuffle at which point everyone is equal.

>> I think that if it's
>> possible, it would also be nice to be able to specify parameters for
>> DHCP options 209, 210 and 211 (config, prefix and reboot) when doing
>> it ourselves.  However, editing the cached packets that the PXE stack
>> holds is a little dirty, unstable but needed.
>
> Yes; editing the cached packets is definitely needed, because some NBP's
> really need us to rewrite the siaddr and bootfile fields in order for
> anything useful to happen.  I agree that being able to add/edit other
> options would be useful; that's the sort of thing that's really too complex
> to do in PXECHAIN.ASM but ought to be reasonable for a COM32 module.
>
>> Proposed command line:
>>
>> -Do it ourselves (or tell gPXE to; partially implemented)
>> pxechn.c32 _new_nbp_ [config [prefix [reboot]]]
>>
>> where reboot is converted with strtoul and all other arguments are in
>> any applicable format (URL or PXELINUX-specific format) or a special
>> ignore character/string (probably "-" or "--" would be best) to allow
>> the later arguments to be specified.  I think this order would
>> probably provide the most common and logical order (since I'd think a
>> user is less likely to override the later arguments).
>
> I wonder if it's worth doing actual getopt-style processing for the later
> arguments.  That would allow any combination, as well as allowing for future
> expansion to provide other DHCP options.

pxechn.c32 _new_nbp_ [-c config] [-p prefix] [-t reboot]

would seem pretty reasonable for a getopt-style.  Another is something
like --209 for option 209.  I'd also consider an argument that makes
it quiet ("-q", "--quiet", or just "quiet" to fit everything else).  I
think having a nice way to display usage from the command line would
also be useful, definitely do so when no arguments are passed but also
consider "-h", "-?", and "--help" for arguments.

As crazy as it sounds I could see the possibility of having the nbp,
config, and prefix all pointing in different directions (if PXELINUX
can/will handle this).

-- 
-Gene

>> -Use PXENV_RESTART_TFTP (not implemented)
>> pxechn.c32 -r [[ipaddress]::]tftp_filename
>>
>> Equivalent to "pxechain.com [[ipaddress]::]tftp_filename"
>
> Sure.
>
> -- Jeff