"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.