DragonFly kernel List (threaded) for 2009-03
DragonFly BSD
DragonFly kernel List (threaded) for 2009-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly boot2 - moved out of commits thread

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Thu, 05 Mar 2009 07:46:47 +0800

Oliver Fromme wrote:
Bill Hacker wrote:
> Oliver Fromme wrote:
> > http://wiki.freebsd.org/OliverFromme/BootLoader
> > > > I think DragonFly should be able to port it over without
> > difficulty. Last time I looked, DF's boot loader was
> > still pretty much the same as FreeBSD's.
> > Good start.
> > And 'compliments' on not going off and coding it in flavor-of-the month > language....

I don't understand that remark.  The boot loader is written
in C, so I don't have much choice other than to code the
graphics support in C, too.  I'm certainly not going to
port the whole boot loader to a different language.  There
aren't many languages anyway that are suitable for such a
rather low-level piece of software.

Once upon a time ... soembody was going to do a bootloader in (IIRC) Lua.

Nice enough language - but why add to the complexity and dependencies when not much *else* is done in the core - or anywhere else - in it.

> (though it is a travesty what FICL'ization has done to the sheer > elegance of 'real' Forth... but that wasn't your doing...)

I don't like Forth.  But some people decided that it should
be embedded in the boot loader, and I can't change that, so
I need to deal with it.

Actually one CAN change it. The CPU won't care.

But you might have liked it better if it hadn't been bastardized by crossbreeding it with C. Properly utilized with its OWN tools, eg to generate 'headerless' (ROM'able, even) code stripped of all but what a specific need requires, it produces extremely space-efficient output - far more compact than asm, odinarily, and 8way8 more portable.

That is half the reason it ended up in a great many boot loaders, where both ROM and disk space were much leaner than they are today.

The other half is that early-on Forth was for many years the most widely ported OS/language on the planet. It is inherently both OS and language, as 'job one' for its 300-odd 'primitives' is to implement a standard 16-bit dual-stack virtual machine with virtual memory manegement whether run on a 2-bit bit-slice or a Cyber-70.

Ray Duncan's LMI Forth made a Z-80 incredibly productive in small RAM.
ISAM's, BoM explosions, 1000 lpm chaintrain printer drivers... ..

. . anyway ...

> As soon as I get a logo into place that doesn't remind me of a chancroid > disease, (not your choice, either ... I hope..)

The background containing the logo is just a PCX file that
can be replaced easily (currently limited to a maximum of
640 x 480 pixels at 4 bit depth).  In fact I've created a
few alternative backgrounds; see the screenshots here:


If you create a theme for DragonFly BSD, I'd be happy to
add it to my collection.

I've made several attemps to modify the published DragonFly logo, but no joy so far.

The 4-bit color-depth is now per your earlier guidance, but the tools I am using are doing something ELSE that is unwanted, so now that it actually loads, I'm getting something that looks like fabric scraps from me Mum's cleaning-rag bag.

BTW, you can also replace the font if you like.

> What is, IMNSHO, missing, is the ability to say 'Oh s**t, wrong device' > and select a menu choice that allows 'REWIND', w/o going through the > whole underlying machine BIOS POST and device scan .... and missing it > again as you answer the phone ...

Well, you can still escape to the loader prompt, change
the root FS path, load a different kernel, and so on.
In theory you can wrap that into a menu and add it to
the GUI, you just need to code a little Forth.

A menu could make a good deal of that much easier to use than what the loader prompt supplies.

But the underlying tools need work also. AFAICS, they are no longer up to the needs of recognizing modern hardware as well as they might do.

> A start might be to actually display the device one is sitting on, AND > all others detected during the prior stage - hopefully with more > spy-work as to what they might hold than the initial boot loader has > space for... IOW - a rescan is in order... then a sub-menu 'Select > another boot device' or some such that is more friendly than dropping > out to the 'mount' prompt.

Sounds useful, indeed.  As said above, it would need a
little Forth code to create appropriate output and menus.
All the necessary information and functions are available
to the Forth interpreter.

Currently my primary goal is to finish the basic graphics
support (VESA modes are next on my to-do list).  My hope
is that someone else will pick up from there and improve
on the Forth code to create better menus, which should
preferably work both in text mode and graphics mode.

"Retired" so far means 'busier than ever' so it is late April before I'll have much time to get back to that.

Keep in mind that there are circumstances where graphics
mode cannot be used, e.g. on serial console or with certain
OOB management systems, or on machines that have graphics
hardware that is currently unsupported.

Best regards

LOL! No need to emphasize *THAT* point to a guy who uses old HP-200LX for a serial terminal!

NetBSD has the only loader I actually like for those..

No - plaintext menus suit me - no need for ASCII frames or drawing that increase the vertical height. Just more choices.

Meanwhile - perhaps you could pick up the DragonFlyBSD logo off the site and see about getting it slimmed-down to a 4-bit .pcx that works?

Or perhaps its creator could do so, given the .pcx parameters?



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]