Re: TODO list for 0.92

[erich]

"Yoshinori K. Okuji" <address@hidden> wrote:

> >   --  Testing for some things, including >4GB machines (I have one
> >     now).
> 
> I think GRUB should work. IIRC, there were some successful reports on
> large memory machines several months ago.

Yeah.  I reviewed some of the code this weekend for various possible
sanity checks, and everything I could think of looks ok.

Plus, I tried it on my brand-spanking new 6GB machine, and it works
great.  The way Linux handles the "mem=" option on it's command line
with respect to disjoint memory regions dovetails very nicely with how
GRUB passes it.


Their scheme is natural enough it even makes me tempted to recommend
changing the Multiboot format to remove the BIOS memory map and instead
pass the memory map on the command line, since in general text/human-
readable information is easier to work with, and I don't think it would
be harder than the memory map interpreter that people already have to
write into their kernels.

Oh well, that and maybe other Multiboot info bits being passed as
text/human-readable is food for thought.  I've been getting more
opinionated about such things as I go further into working on my own
OS project.  I'm kind of imagining going back to an ultra-simple MB
info block with just lower/upper memory (i.e. the info you need RIGHT
AWAY before you can even, say, allocate a stack), then a bunch of text
bits that are optional.

The VERY cool thing about the extra bits being text is that, done
right, a human could override/rewrite those bits if desired, OR they
could be added by a human while using a bootloader that doesn't support
those fields.  So, you can smoothly use new fields in newer OSes while
an older bootloader doesn't support them.  Cool, eh?

I would like to discuss this idea further in the context of looking
at Multiboot ver 0.7.  I'm in the process of reviewing it.


One minor/somewhat cosmetic issue in GRUB, when displaying the memory
information from the map (my old "displaymem" command), it displays
lengths in decimal, which is kind of crude and hard to interpret.

I feel tempted to switch it to hex, especially after trying it out and
finding it much easier to interpret.  Would you or anyone else you
know of care?


> >   --  Do Linux boot support for SETUP code version 2.02 (I think
> >     that's the version at least).  Maybe someone has done
> >     this already (haven't checked the CVS archive in the last
> >     month or so...)?
> 
> Do you mean supporting the new feature in 2.02 (i.e. putting a
> command-line arbitrarily)? For now, GRUB doesn't use this feature in a
> useful way, but just sets the command line pointer to the (old) fixed
> place.

Yes.  There are some very specialized boards/machines that don't work
because they have abnormally large EBDA areas, and I have an itch to
make even those work.


--
    Erich Stefan Boleyn     <address@hidden>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"