On Thu, Jan 26, 2023 at 1:06 PM Warner Losh <imp@bsdimp.com> wrote:
>
> Greetings,
>
> My name is Warner Losh and I integrated a google summer of code project that changed FreeBSD's boot loader to use lua as its scripting language. This has gone great for years, but some of my changes have caused a little bit of heart-ache in upgrades.
>
> I took the ZFS (before it was OpenZFS) patches to lua that implemented LUA_FLOAT_TYPE as an int64, cleaned them up and have a small number of changes to the base to make them work. The FreeBSD boot loader must run in environment where one must never touch the floating point unit, and software floating libraries are too large to be included.
>
> The changes to make this happen are surprisingly small. Of course, one can't use fractional numbers in the lua scripts in our boot loader with this, but that's OK. We don't need that aspect of the language to work.
>
> I'd like to get these patches upstreamed. What's the most current way to do this? Should I publish a git branch somewhere? Should I post the patches to the mailing list? Should I go somewhere else? For context (and in case this changes the answer), the patches are rather short:
>
> % git diff vendor/lua/5.4.2 HEAD:contrib/lua --stat
> src/lstrlib.c | 27 +++++++++++++++++++++++++--
> src/luaconf.h | 2 +-
> src/lvm.c | 7 +++++++
> 3 files changed, 33 insertions(+), 3 deletions(-)
> with another 15-ish lines that would be in the luaconf.h file had the one change here been to add a #include "luaconf.local.h" where the boot loader #undefs and #defines live.
>
> The question I have is stylistic or maybe what's the best way to upstream. Nearly all the patches are of the form:
>
> @@ -1121,6 +1121,7 @@ static void addquoted (luaL_Buffer *b, const char *s, size_t len) {
> }
>
>
> +#if LUA_FLOAT_TYPE != LUA_FLOAT_INT64
> /*
> ** Serialize a floating-point number in such a way that it can be
> ** scanned back by Lua. Use hexadecimal format for "common" numbers
> @@ -1149,7 +1150,7 @@ static int quotefloat (lua_State *L, char *buff, lua_Number n) {
> /* for the fixed representations */
> return l_sprintf(buff, MAX_ITEM, "%s", s);
> }
> -
> +#endif
>
> static void addliteral (lua_State *L, luaL_Buffer *b, int arg) {
> switch (lua_type(L, arg)) {
>
> which avoids using float or double. These are the only places where LUA_FLOAT_TYPE is tested in the main code. So maybe a better condition would be something like
>
> #ifndef LUA_NO_FLOAT
>
> instead. That could then be defined in our luaconf.h file and our implementation wouldn't have to go upstream. Or we can upstream it and define LUA_NO_FLOAT as part of it. That would seem to fit better with the other #ifdefs in the code, but I'm unfamiliar with the design patterns preferred by the project.
>
> What can people suggest?
>
> Warner
I've been working on updating Lunatik [1] to Lua 5.4.4 and rebasing it
on Lua's git repository in the past few days; here is the result: [2].
It might be useful for disabling floating points completely. Please
notice, it's still experimental right now for 5.4.4 (5.3.6 [3] is way
more mature though).
[1] https://github.com/luainkernel/lunatik
[2] https://github.com/luainkernel/lua/compare/v5.4.4...luainkernel:lua:lunatik
[3] https://github.com/luainkernel/lua/tree/v5.3.6-kernel
These changes are quite a bit more extensive than the ones that I have. i just eliminate the use of floating point
in the 8 places that it is used today. I've gone ahead and created a branch on github. Our standalone environment
emulates userland includefiles so we don't need the extensive changes for that which lunatik has. It's based
entirely on LUA_OMIT_FLOATnot being defined. Users can define it in their luaconf.h file. It doesn't have the
LUA_FLOAT_TYPE based on int64_t, though. I could add that if there's interest with a change to luaconf.h.
We've used changes like this for a long time (since I think lua version 5.2) in FreeBSD's boot loader, most
recently on v5.4.2 (though the branch I pushed is slightly different than what we use, since it's based on the
latest master branch).
Warner
Regards,
--
Lourival Vieira Neto
