Date: Mon, 02 Nov 1998 14:58:19 -0800 From: Mike Smith <mike@smith.net.au> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels Message-ID: <199811022258.OAA02025@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 03 Nov 1998 09:35:43 %2B1100." <98Nov3.093515est.40322@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> To join in the general discussion: I support the idea of FORTH in the > bootloader. It's small, reasonably fast and extensible. I like the > idea of a bootloader that fits into the bootblocks - which puts a > hard upper limit on the size. It will never fit in the "bootblocks". It's all we can do to locate a file in the filesystem and read it in. Before being too dim about this, bear in mind that no other operating system bootstrap manages to achieve this much with so little. > As a general comment, once you start cutting down a standard, well- > known language, it gets harder to work with. You have to remember > which features no longer work (or, worse, behave differently). I > would not like to see a mini-sh, mini-tcl, mini-perl or tiny-C as > a bootloader language. Good points, and why we haven't made any effort to expand the current interpreter lately. > Whilst shell is well known, it is much larger - and relies on external > code (which assumes the kernel is running) for most commands. The > more commands you build into the shell, the bigger it gets. It's not > readily extensible, so it's difficult to hide the underlying language. > Similarly, tcl is large and non-extensible. Tcl is quite extensible (very extensible actually), but much too large. > On a slightly related issue, some time ago, Greg Lemis and I were > discussing the possibility of replacing DDB with something that > included a command language. This is another area where bloat is > undesirable and I suggested FORTH. There would be obvious benefits > in having a common extension language used by the bootloader and > kernel debugger. There would be little trouble including the FICL Forth engine in the kernel; I had actually considered the not insubstantial advantages to doing this (most importantly the ability to attach Forth to modules to do specialised load/unload operations), but I suspect that this will be viewed too much like heresy by many people. > FORTH does have a decent pedigree as a bootloader - Sun have been > using it for at least 6 years. Most user interaction is covered > by "boot FILE FLAGS", "reset" and "sync" - you don't have to be > a FORTH guru to use it. That's my hope. We also have enough manifest Forth talent to get us bootstrapped to that stage, so I don't view it as technically impossible. The philosophical issues are still bugging me. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811022258.OAA02025>