On Thu, 2 Aug 2001, Mario Klebsch wrote:
> Yes, in a way, it does make sense. But remember, there is no standard
> for passing this information. The 'mem='-Parameter is just the
> Linux-sollution. What if *BSD, Darwin, BeOS, OS/2, OS-9000 or watever
> OS you might want to boot, requires a different argument? Wat if the
> unknown OS does wiered things, if it gets the mem= parameter?
BSD has their own arrangement, there's nothing new there. BeOS, OS/2,
etc., all chainload, afaik. Darwin uses Mach, therefore it should be
Multiboot-compliant by default, and therefore get a memory map as part of
the Multiboot info block when you boot it.
> Doing it the Linux way in grub as a general sollution sounds weired to
> me. And IMHO passing a single numer does not qualify as a general
> sollution. OS-9 for example, is passed a table of memory regions.
The mem= append only applies to Linux, but memory info is passed to
Multiboot compliant kernels. If everyone would make their kernels
Multiboot compliant, that'd make things easier. (Probably wouldn't have
eliminated my problem, which is due to a buggy BIOS giving out bad info.)
Like there's no OS-specific stuff for FreeBSD/NetBSD/OpenBSD kernels in
GRUB also?
> Since only Linux (especially only oder versions of it) require this
> option, I don't like the idea, to require a command line option to not
> pass this option.
I've never known Linux to _require_ it. I've used Linux since the 1.2
kernels were still recent. The only problem was with some older machines
that still had broken memsize reporting, and couldn't report anything
larger than 64 MB of system RAM, so you had to pass a mem= option to tell
Linux how much memory there really was if they were outfitted with more
than 64 MB. That's been a non-issue since the Pentium line, to my
knowledge.
> What about adding a configure option?
Read the NEWS file in the GRUB source. There is a flag that can be passed
to ./configure to make it not pass the mem= option to the Linux kernel at
all. However, it shouldn't matter - with the patch I submitted earlier,
the memory reporting issue is worked around with a one-line fix.
Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet
[EMAIL PROTECTED] | District (dsdk12.net) | #linuxOS on OPN
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
