Syslinux - Aug 2013 - Automatic boot menu?

"H. Peter Anvin" <hpa at zytor.com> writes:
> On 08/22/2013 10:20 AM, Ferenc Wagner wrote:
> 
>> Now that Syslinux has ls.c32 and lua.c32, it should be possible to
build
>> a customizable boot menu in the bootloader itself, instead of
generating
>> it beforehand by hooking into the kernel installation/removal process.
>> Sure that would not work over TFTP (no ls), but the already mentioned
>> 20th century way would not either.  Sadly, directory handling is not
>> implemented in the embedded Lua interpreter, or at least I failed to
>> find it.  Is there perhaps some deep reason for this?  Or is this idea
>> useless anyway?
>> 
>
> No, there isn't any reason for that.  It's just a matter of noone
having
> done it yet.
>
> It would be a very good thing to get this done.
Thanks, glad to hear it.  And would it be necessary to reimplement the
menu system in Lua, or would it be possible to hand over the generated
config to menu.c32 somehow?  If not, then maybe extending menu.c32 with
some "dynamic" directives would be a lot easier.  Unfortunately that
would restrict the functionality to the simple menu system and also make
it more rigid, but that's probably the bulk of the use cases anyway...
-- 
Regards,
Feri.

On 08/29/2013 04:14 AM, Ferenc Wagner wrote:
> "H. Peter Anvin" <hpa at zytor.com> writes:
> 
>> On 08/22/2013 10:20 AM, Ferenc Wagner wrote:
>>
>>> Now that Syslinux has ls.c32 and lua.c32, it should be possible to
build
>>> a customizable boot menu in the bootloader itself, instead of
generating
>>> it beforehand by hooking into the kernel installation/removal
process.
>>> Sure that would not work over TFTP (no ls), but the already
mentioned
>>> 20th century way would not either.  Sadly, directory handling is
not
>>> implemented in the embedded Lua interpreter, or at least I failed
to
>>> find it.  Is there perhaps some deep reason for this?  Or is this
idea
>>> useless anyway?
>>>
>>
>> No, there isn't any reason for that.  It's just a matter of
noone having
>> done it yet.
>>
>> It would be a very good thing to get this done.
> 
> Thanks, glad to hear it.  And would it be necessary to reimplement the
> menu system in Lua, or would it be possible to hand over the generated
> config to menu.c32 somehow?  If not, then maybe extending menu.c32 with
> some "dynamic" directives would be a lot easier.  Unfortunately
that
> would restrict the functionality to the simple menu system and also make
> it more rigid, but that's probably the bulk of the use cases anyway...
> 
One of the main reasons for the code restructuring into ELF libraries is
that we should be able to set up configurations in memory.  There are
two ways we could do that... either by manipulating the menu data
structures and just making them persistent, or by introducing a concept
of "in-memory files" which persist across modules.

Which one would you think would be easier?  The downside of the latter
is that the existing menu structure would not be available, but the
upside is that we wouldn't be introducing a whole new interface...

	-hpa

On Thu, 2013-08-29 at 06:14 -0700, H. Peter Anvin wrote:
> One of the main reasons for the code restructuring into ELF libraries is
> that we should be able to set up configurations in memory.  There are
> two ways we could do that... either by manipulating the menu data
> structures and just making them persistent, or by introducing a concept
> of "in-memory files" which persist across modules.
> 
> Which one would you think would be easier?  The downside of the latter
> is that the existing menu structure would not be available, but the
> upside is that we wouldn't be introducing a whole new interface...
It would also provide considerable flexibility for other uses...

"H. Peter Anvin" <hpa at zytor.com> writes:
> On 08/29/2013 04:14 AM, Ferenc Wagner wrote:
>
>> "H. Peter Anvin" <hpa at zytor.com> writes:
>> 
>>> On 08/22/2013 10:20 AM, Ferenc Wagner wrote:
>>>
>>>> Now that Syslinux has ls.c32 and lua.c32, it should be possible
to build
>>>> a customizable boot menu in the bootloader itself, instead of
generating
>>>> it beforehand by hooking into the kernel installation/removal
process.
>>>> Sure that would not work over TFTP (no ls), but the already
mentioned
>>>> 20th century way would not either.  Sadly, directory handling
is not
>>>> implemented in the embedded Lua interpreter, or at least I
failed to
>>>> find it.  Is there perhaps some deep reason for this?  Or is
this idea
>>>> useless anyway?
>>>
>>> No, there isn't any reason for that.  It's just a matter of
noone having
>>> done it yet.
>>>
>>> It would be a very good thing to get this done.
>> 
>> Thanks, glad to hear it.  And would it be necessary to reimplement the
>> menu system in Lua, or would it be possible to hand over the generated
>> config to menu.c32 somehow?  If not, then maybe extending menu.c32 with
>> some "dynamic" directives would be a lot easier. 
Unfortunately that
>> would restrict the functionality to the simple menu system and also
make
>> it more rigid, but that's probably the bulk of the use cases
anyway...
>
> One of the main reasons for the code restructuring into ELF libraries is
> that we should be able to set up configurations in memory.  There are
> two ways we could do that... either by manipulating the menu data
> structures and just making them persistent, or by introducing a concept
> of "in-memory files" which persist across modules.
>
> Which one would you think would be easier?  The downside of the latter
> is that the existing menu structure would not be available, but the
> upside is that we wouldn't be introducing a whole new interface...
Unfortunately I'm not familiar with the current (planned?) architecture
for this.  Should the core profit from this?  I added some DHCP macros
before, so I think it should (optionally).  A wholesale solution would
be adding the possibility of Lua configuration files, for example using
syslinux.lua if lua.c32 is present).  This may even be possible without
changing the internal data structures representing the configuration,
and would only require a new entry point into menu.c32, skipping the
config file parsing.

Another way would be adding Lua "escapes" to the current configuration
language, executing files or code blocks and substituting strings.  This
would still require the current parser in the end, which feels wasteful.

Rewriting the complex menu system in Lua would open new UI possibilities
as well, while removing the need for recompilation, lifting its main
weakness.  Or maybe adding new dotcommands to menu.c32 which invoke Lua
functions manipulating its internal data structures would mean a shorter
path there...

Anyway, I would prefer optional deeper integration to ad-hoc bolts-on.
-- 
Regards,
Feri.