[syslinux] Problems with gfxboot.c32

[H. Peter Anvin]

On 06/20/2014 07:31 AM, Colin Watson wrote:
> 
> Sorry for not noticing this thread for such a long time.  We only ran
> across this rather recently when we switched to syslinux 6 and found
> that our boot menu broke ...
> 
> This is really pretty problematic for us.  Yes, it's possible for us to
> work around this change by adding some more files to the packed archive,
> and I'll probably do that in the short term.  However, some of these
> files are required outside the archive as well (gfxboot.cfg at least),
> and so that means we'll end up duplicating things; and the image files
> routinely have to be changed by people customising Ubuntu images, which
> is a pretty common use case for us.  I anticipate this being a
> non-trivial source of confusion for people building images based on
> ours.
> 
> I'm sure it isn't trivial to reintroduce the COMBOOT API.  Is there any
> other sensible way that this feature might be reintroduced?
> 
> (Incidentally, the statement about GRUB above makes little sense to me,
> unless maybe it's talking about GRUB 1.  GRUB 2 is perfectly happy to
> read files directly off an ISO9660 filesystem or basically whatever else
> it comes across.)
> 

The COMBOOT API has lived its run, it simply cannot be sanely brought
back to life.  It wouldn't work with something like EFI no matter how
much work we did.

This ultimately comes back to a request of mine since at least 10 years
to get (all of) gfxboot rewritten in C so it can be made to operate
against a more general framebuffer framework.

I don't have a good solution for this.  It is a sizable project to
rewrite the gfxboot byte code interpreter in C, I suspect, but at least
it ought to be *doable* ... which is the good part of gfxboot being a
byte code interpreter at all.

It really is just a resource issue.

	-hpa