Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: New new enhanced memory detection patch; testers wanted | Date | Tue, 23 Feb 1999 01:08:16 -0500 |
| |
> Has anyone thought about possibly supporting the MultiBoot standard? If we > moved memory detection and such to the boot loader, we could stop having to > constantly update the kernel for that kind of thing... Plus, it uses a much > better system for passing information :)
The problem with the boot loader approach is that it doesn't work when the kernel is not loaded with a boot loader, such as when booting from a kernel dd'd to a floppy. In the past I've had to do this for a couple of machines, plus one I've still got today, who's BIOS didn't support the installed hard drive's native capacity. These el cheapo drives didn't come with a compatable version of disk manager which leaves booting from a dd'd kernel on a floppy the best cost/time effective solution. This is not even mentioning the emergency boot floppies (kernels' dd'd to floppies) that I keep around in case something goes wrong with LILO. Time = money + free time, so having to boot with a boot floppy to get a LILO damaged machine back up, then reinstall LILO, and then reboot again so that the boot loader could redetect the correct amount of memory to pass to the kernel could easy add downtime costing Linux users both precious time and $. As far as constantly modifying the kernel for this kind of thing I do not think memory detection methods will change much if at all; it is against the hardware maker's interests to do so (unless necessary), at least without backward compatability, as this would make their hardware incompatable with a significant portion, if not all, of the OSes out there; cutting their potencial market share.
> (I wouldn't mind being able to specify the root in the bootloader without using > a root=... kernel option)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |