Date: Sun, 24 Aug 2014 15:53:45 -0700 From: <dteske@FreeBSD.org> To: <freebsd-hackers@freebsd.org> Cc: "'Wojciech A. Koszek'" <wkoszek@freebsd.org>, dteske@freebsd.org, 'Pedro Giffuni' <pfg@freebsd.org>, 'Pedro Arthur' <bygrandao@gmail.com> Subject: FW: Lua in the bootloader Message-ID: <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <A87AA9EB-373F-400E-986E-4D9017EB2375@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey List, Looks like the Lua Loader GSoC project went well as I'm sure a lot of projects did (including my own student's). I had some time to review the Lua Loader GSoC project results (code-wise) and provide in-depth, detailed feed- back on a hypothetical proposition: keeping Forth but making Lua the default. I'm not against the proposition, quite the contrary. The limitations that I battle in Forth are significant enough that I'd like to see if Lua can break said chains (such as "dictionary full" errors causing BTX halt -- induced simply by adding "too many functions" in Forth). Please read below my comments which the GSoC student (Pedro Arthur <bygrandao@gmail.com>) and mentor (Wojciech A. Koszek <wkoszek@freebsd.org>) wanted me to share with the mailing lists (I chose -hackers). -- Cheers, Devin > -----Original Message----- > From: Devin Teske [mailto:devin@shxd.cx] > Sent: Saturday, August 23, 2014 7:40 PM > To: 'Pedro Giffuni' > Cc: 'Julian Elischer'; 'dteske@freebsd.org' > Subject: RE: Lua in the bootloader > > From: Pedro Giffuni [mailto:pfg@freebsd.org] > > Sent: Friday, August 22, 2014 11:01 PM > > To: dteske@freebsd.org > > Cc: Julian Elischer > > Subject: Re: Lua in the bootloader > > > > Il giorno 22/ago/2014, alle ore 22:36, dteske@freebsd.org ha scritto: > >> > >>> -----Original Message----- > >>> From: Pedro Giffuni [mailto:pfg@freebsd.org] > >>> Sent: Friday, August 22, 2014 6:21 PM > >>> To: dteske@freebsd.org > >>> Subject: Lua in the bootloader > >>> > >>> Hi Devin; > >>> > >>> JFYI, It looks like, against my forecast, the Lua project was successful: > >>> > >>> https://wiki.freebsd.org/SummerOfCode2014/LuaLoader > >>> > >>> I haven't looked at the code but it is actually good news as it seems > >>> like we can keep both in the tree :). > >> > >> In related news, I'm making the necessary changes to > >> support ZFS enumeration in the loader. > >> > >> Oh, and btw... the changes I'm making in are in *C* and will effect > >> are going to make it possible to enhance the Forth code to produce > >> a dynamic boot menu where the user can select the ZFS root pool. > >> > >> The reason why I have to modify the C code is because Forth does > >> not support Inter-Process Communication (IPC) components such > >> as pipes. So although the loader environment provides the FICL > >> word "lszfs", that command uses printf directly to print to the > >> screen (to which Forth cannot ``catch'' via pipe from FICL). > > > > Very cool! > > > > I don't know Lua but it does support pipes: > > > > http://www.lua.org/pil/9.2.html > > > > I am starting to wonder if we will end up dumping forth altogether. > > > > Let's not be so hasty. > /me goes and reviews what the Lua GSoC was able to accomplish. > > Hmmm, I'm actually impressed. It got a lot further along than I had > predicted. That being said, I still have to point out several short- > comings that need to be addressed before we switch over to Lua: > > === > > 1. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/drawer.lua > > function drawer.isColorEnabled() simply returns true. > Contrast that with the following: > > http://www.freebsd.org/cgi/man.cgi?query=color.4th > http://svnweb.freebsd.org/base/head/sys/boot/forth/color.4th?view=mark > up > > NB: boot_serial? is defined here... > http://svnweb.freebsd.org/base/head/sys/boot/forth/support.4th?view=m > arkup > > Basically, the drawer.isColorEnabled() function needs to check a > series of environment variables to produce the proper response > (versus the obvious mistake of simply always returnining true). > > Those environment variables are (in no particular order): > $console, $boot_serial, $boot_multicons, $loader_color > > if $console contains "comconsole" (space or comma separated) > then drawer.isColorEnabled() should return False > > if $boot_serial is set to a non-NULL value, then > drawer.isColorEnabled() should return False > > if $boot_multicons is set to a non-NULL value, then > drawer.isColorEnabled() should return False > > if $loader_color is set to "0" or "NO" (case insensitive) then > drawer.isColorEnabled() should return False > > Returning the wrong result in the wrong situation (e.g., always > returning True) can cause unexpected results. > > === > > 2. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > The menu.run() function always uses ANSI escape sequences. > Contrast with the beastie-start function in the following: > > http://svnweb.freebsd.org/base?view=revision&revision=265028 > > menu.run() needs to check a series of environment variables: > $console, $beastie_disable, $loader_delay > > if $console contains (space or comma separated) "efi" then do > not draw a menu (fall back to autoboot routine). > > if $beastie_disable is set to "YES" (case insensitive), then do not > draw a menu (fall back to autoboot routine). > > === > > 3. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2. > > menu.options.alias associative array should be merged into > the menu.options plain array. (this will be an utter requirement > if solving the stateful menu system issues below) > > Same thing goes for the boot.options.alias associative array. > > === > > 4. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2 and #3. > > menu.options associative array defines kernel menu as > "not available" if $kernels is undefined. This is actually > incorrect when compared to what the Forth code does. > > Not only $kernels is probed, but $kernel is also probed. > In fact, the Forth code checks $kernels for $kernel... if > $kernels contains $kernel (space or comma separated) > then you can think of the list presented as $kernels. But > if $kernels does not contain $kernel, then $kernel is > appended to the menu list of kernels. This part is very > important (it means $kernel and $kernels can be given > unique values but both are used to present menu > options). > > === > > 5. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2, #3, and #4. > > menu.options associative array has static menu items > for the first two items defined: > > 1. Boot Multi user [Enter] > 2. Boot [S]ingle user > > In the Forth code, items #1 and #2 have "toggled values": > > 1. Boot Single user [Enter] > 2. Boot [M]ulti User > > When the environment variable (e.g., from loader.conf(5)) > $boot_single is set to non-NULL, the Forth code reverses > the #1 and #2 menu items, indicating that the default action > as-configured via loader.conf(5) (or manually by dropping > to the loader(8) interactive Forth prompt) using $boot_single. > > Reference: > http://svnweb.freebsd.org/base?view=revision&revision=243660 > > === > > 6. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2, #3, #4, and #5. > > menu.options associative does not support setting non-ANSI > colorized versus ANSI colorized captions on menu items. > > Contrast with the following: > http://svnweb.freebsd.org/base/head/sys/boot/forth/menu.rc?view=mark > up > > Use of ANSI caption versus non-ANSI caption should be based > on the return of drawer.isColorEnabled() -- which leads me to > state that perhaps that function (isColorEnabled) is probably > better-off being part of the loader objects (more closely relating > to the Forth code wherein the counter-part is "loader_color?" > function). > > === > > 7. [Extra credit] The Forth code implements an optional delay that > can be introduced just prior to rendering the menu. See below: > http://www.freebsd.org/cgi/man.cgi?query=delay.4th > The Lua code does not implement this feature. > > === > > 8. [Minor Nit] It should be "On"/"off", not "On"/"Off" (as it is > currently in menu.lua). The reason for this is "accessibility" for > disabled persons (generate wider variance between on/off > states for higher visual impact by using case variance as well > as color variance -- for those times color is disabled or you have > a color-blind viewer). > > === > > That's all for now. Please don't take this as a scathing review of > why it's not ready, but rather I'm very happy that we're able to > have this type of discussion (of the minor/major short-comings > versus, say, in-operability). I'm very happy that the GSoC project > was able to make it this far. The door is really truly open in my > mind for Lua possibly replacing Forth. Forth has a lot of limitations > and I gladly welcome Lua if (and only if) we can get it up to snuff. > > If the above issues can be resolved, we have a really good chance > of making Lua the new default. > > >> I don't know if Lua supports IPC or pipes, but if it did then that would > >> mean that it would conceivably already (today) present a menu of > >> ZFS datasets to select as the root device. However, despite whether > >> it has pipes or not, the code that I am changing is in the zfsimpl[e].c > >> code which is the "ZFS Simple Implementation" code of the loader. > >> This is at a layer below both Lua and Forth. The enhancement that > >> I am making starts with teaching the previously mentioned code that > >> currently prints to screen to instead take a by-ref handle argument > >> so that we can make a new function. Said new function would, unlike > >> lszfs, pass a meaningful pointer (instead of NULL) to store the response > >> in memory as an array of strings (char *) that can then be (wait for it)... > >> > >> ...set as a series of environment variables. > >> > >> Forth can surely preen the environment variable namespace and has > >> no problems interacting at that layer (bystepping the problem of not > >> having true IPC in Forth). > >> > >> It is expected that these changes to zfsimpl.c et. al. will benefit Lua > >> because Lua can then preen the environment variable namespace > >> after making a call to a loader-provided function. > >> > >> For example, (pseudo-code; I had doubts you wanted to read Forth): > >> > >> zfs_probe zroot/ROOT > >> for (n = 0; $n < ${zfs_list_max:-0; n++) > >> push(@menu, $zfs_list_item[n]); > >> > >> NB: Yes, I just mixed C, Perl, Shell, and Forth into some weird pseudo- > code > > > > > > Pretty ugly If you ask me .. but I have never wanted to learn Perl ;). > > > > Heh. What's in a language anyhow if it helps people communicate well? > -- > Cheers, > Devin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16e101cfbfee$42b3b930$c81b2b90$>