[syslinux] [RFC, PATCH] core/pxe: Add architecture-specific discovery request for PXE config file

[Jeremy Kerr]

Hi hpa,

> Ok, that makes sense.  PXELINUX had become a de facto standard and
> has in fact been extended with ipv6 support by agreement between me
> and Peter Jones, used in at least some versions of Grub.

Yep, exactly. This is why I'm proposing the patch to you folks first :)

> Here is the problem I see: arch discovery is orthogonal with
> address-based discovery.  It creates a complex problem because we
> don't want to try all possible combinations.

It is orthogonal, but I don't think that necessarily results in
combinatorial explosion of potential request paths. I see there being
two main scenarios for large-scale pxe usage:

 1) those where individual machines are tightly managed, and boot
    parameters are known in advance. Each machine is "registered"
    before booting. The UUID, MAC and lease-IP discovery requests
    are handy for this scenario.

 2) those with a "plug and play" approach to machine deployment;
    new machines can be racked and booted, and the infrastructure
    doesn't need prior knowledge of the boot parameters for
    individual machines (however, machines can register themselves
    as part of the initial provisioning).

    The "default" discovery requests are handy for this scenario, but
    *only if* you have a homogeneous set of machine architectures (so
    the one boot configuration suits all machines).  Hence, the arch-XXX
    requests to allow this.

I don't foresee these two scenarios being mixed in a way that requires
combining the orthogonal behaviours. Perhaps someone will use arch-XXXX
for machine provisioning & self-registration (which generates a
machine-specific conf file named by UUID), and then UUID for subsequent
boots, but that's still a separate boot process.

> The final option is to introduce macros that can be used in an
> include statement, so the file fetched would be a generic config file
> which can include others based on all kind of parameters, making most
> of the discovery junk unnecessary.  It also lets the sysadmin keep
> the common bits common.  Personally this is the option I like the
> best.  iPXE has been doing this for years.

That sounds good, but arch-XXX is a fairly unintrusive change to the
process (ie, doesn't require any changes to the config syntax & parser
implementations). Would you expect other loaders to implement the
includes (and parameterisation)? That would definitely be possible to
implement in petitboot, but I do have the luxury of a full flex/bison
parser :D

I've just been digging through u-boot, and it looks like they request
"default-<arch>" (and possibly "default-<arch>-<board>") already. The
difference being that <arch> isn't a well-defined name (it's just a
string defined by uboot). I'd prefer to use the IANA identifiers, and
will still submit the arch-XXXX patch to them for feedback, but that's
not crucial.

Cheers,


Jeremy