Date: Mon, 25 Aug 2014 10:34:42 -0700 From: <dteske@FreeBSD.org> To: "'Jordan Hubbard'" <jkh@ixsystems.com>, "'Rui Paulo'" <rpaulo@felyko.com> Cc: "'Wojciech A. Koszek'" <wkoszek@freebsd.org>, freebsd-hackers@freebsd.org, dteske@FreeBSD.org, 'Pedro Giffuni' <pfg@freebsd.org>, 'Pedro Arthur' <bygrandao@gmail.com> Subject: RE: Lua in the bootloader Message-ID: <181801cfc08a$db080730$91181590$@FreeBSD.org> In-Reply-To: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <A87AA9EB-373F-400E-986E-4D9017EB2375@freebsd.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: Jordan Hubbard [mailto:jkh@ixsystems.com]
> Sent: Sunday, August 24, 2014 11:27 PM
> To: Rui Paulo
> Cc: <dteske@FreeBSD.org>; <freebsd-hackers@freebsd.org>; Pedro Giffuni;
> Wojciech A. Koszek; Pedro Arthur
> Subject: Re: Lua in the bootloader
>
>
> On Aug 24, 2014, at 9:07 PM, Rui Paulo <rpaulo@felyko.com> wrote:
>
> > No, it's worse than that. There's not a really limit on the size and
the stack
> can overflow easily on real hardware while at the same time it works fine
on
> bhyve at the same time. userboot vs real hardware.
>
> I'm not sure I understand why there would be a difference in behavior on
> "real hardware" vs bhyve unless bhyve is initializing ficl differently and
> causing it to change its allocation parameters.
Indeed, there are differences in the way FICL is brought up.
IIRC, bhyve uses "userboot" which does not provide an exact match
to the loader environment (it can't exactly match everything).
As an example, I'll draw a parallel with the "testmain" program.
Here's an excerpt from sys/boot/ficl/loader.c:
#if TESTMAIN
/*
* The readdirfd() function is specific to the loader environment.
* We do the best we can to make freaddir work, but it's not at
* all guaranteed.
*/
In that excerpt, I'm drawing attention to the fact that the "testmain"
program which I use to simulate Forth in multi-user environment does
not have access to readdirfd(). Outside of the loader environment,
ficl itself has to fake a few calls.
FYI: readdirfd() is provided by libstand, used by loader.
> In some ways, we lost out for
> not having gone with "a real forth" implementation in the most traditional
> and compact sense. In a traditional Forth system, the dictionary starts
at the
> bottom of the available address space and the stack starts at the top -
they
> grow towards one another, which is how I implemented the PC-532 boot
> loader (also in forth, but in assembly language); if you want to keep them
out
> of their hair, you just put the stack base further away in memory.
>
That seems like a reasonable approach without making me worry about
PC's of yester-year.
> Ficl is a higher-level C implementation and simply allocates a fixed-sized
> chunk of space for the dictionary and for the stack. Our version of ficl
is a bit
> ancient and I'm still looking through it to even see where the dictionary
size is
> chosen. I suspect we simply made some bogus assumptions early on and
> never caught them until the FreeBSD boot environment grew so many logos
> and menus that it hit the limit.
>
Oh, you jogged my memory that some folks wanted me to update the Ficl
implementation in the loader to the latest version.
> Not that I disagree with any of the other arguments, mind you. I think a
new
> boot environment language would be fine. I agree that Forth is largely
only
> attractive to people with grey beard hair (though its value for torturing
Alfred
> should not be underestimated). I just think that it's also going to be
awhile
> before the new hotness is at full feature-parity with the current boot
loader,
> and if fixing the amount of headroom can buy us a little time, why not?
We
> hit the limit with FreeNAS too (I've seen the same dreaded boot-time crash
> you did) so it's not just an academic point for me.
>
Ah, then we agree. Lua can spin in a silo while we address Forth issues.
1. Updating FICL to the latest version
2. Adjusting dictionary size (by pushing stack out?)
3. Taking the menus even further (ZFS root selection; i.e., beadm)
> > The limitation of the dictionary and the size of the stack isn't the
main
> reason why I would prefer lua over forth. Why do we need to subject
> ourselves to a stack based language in 2014? The very limited number of
> people hacking on the Forth boot loader on FreeBSD might have a different
> opinion, but the language is so arcane that I fail to see why we shouldn't
> replace it.
>
> Again, no disagreement, though I do wonder how many Lua programmers
> FreeBSD has that will be able to hit the ground running as a result of
this
> evolution. Anyone? Raise your hands! I can't raise mine - I've never
used
> Lua. :)
>
Seeing that the GSoC project re-envisioned a lot of my Forth code, I feel
that I was able to pickup Lua pretty fast. Not sure how fast others can
(that
is, without the benefit of seeing in the context of their own code a direct
translation).
--
Devin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?181801cfc08a$db080730$91181590$>