Date: Mon, 25 Aug 2014 15:24:43 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Jordan Hubbard <jkh@ixsystems.com>, Rui Paulo <rpaulo@felyko.com> Cc: "<freebsd-hackers@freebsd.org>" <freebsd-hackers@freebsd.org>, Pedro Giffuni <pfg@freebsd.org>, "<dteske@FreeBSD.org>" <dteske@FreeBSD.org>, "Wojciech A. Koszek" <wkoszek@freebsd.org>, Pedro Arthur <bygrandao@gmail.com> Subject: Re: Lua in the bootloader Message-ID: <53FBB7AB.2080008@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
On 8/24/14 11:27 PM, Jordan Hubbard wrote: > 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. 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. > > 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. > > 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. > >> 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. :) Probably about the same amount of Forth coders, if not more. That said the bar to entry with Forth is so much higher (for very little gain) these days that it just makes sense to retire it, or at least offer other options. Seriously, the entire use of Forth in the loader has been done wrong and it is due to Forth being hard to develop in, specifically for C programmers. We do just so many things wrong, and the only thing we're actually doing in forth is emitting ascii code, and now that we have color prompts by default "printenv" is broken. It's just rage inducing and makes FreeBSD (and by extension us (and by that extension me)) look dumb and archaic. Let's get something that's easy to code in and call it a day. I recall taking half a day in order to figure out some magic to help some poor sysadmin pick an include file using a DHCP env var, and *days* working with Devin to just conditionally make a construct to "include file if it exists". Yech! Lua please. -Alfred > > - Jordan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53FBB7AB.2080008>