Re: Re[2]: [Etherboot-developers] Q: does xstart work?
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Eric W B. <ebi...@ln...> - 2002-07-25 03:56:35
|
Anselm Martin Hoffmeister <an...@ho...> writes: > Hello Eric, list, > > EWB> Probably the fun part is keeping track of which areas have been allocated > EWB> to the partially loaded image. > > >> I'm not so concerned about the text segment size of Etherboot when > >> Etherboot is converted to run high. In the current version the main > >> concern is the 48kB limitation. I think there are few machines that > >> can't spare a couple of hundred kB from the top of memory during the > >> image loading phase. One is not supposed to load memory to brim anyway, > >> Linux will need room to expand when it gains control. > > EWB> Except when you have a ramdisk. But a sane implemenation will load > EWB> the ramdisk low, and then push it up higher if required. Though I seem > EWB> to like the insane varieties. > > As I see it, Eric, you used the last room for just beyond land's end > for SLAM downloaded data stuff. BTW, I copied that idea, so the last > [image-block-num]*[image-block-size] bytes of memory are used for that > purpose in TFTM too. No problem to spare the last say 300kB, but one > must not forget! Agreed. That has been a FIXME in my code for a while. Getting etherboot to relocate itself was the interesting part of this adventure. When I get the code checked in there will be a lot of small little fixes that need to propogate through etherboot to fix this. Unless the multicast file has always loads into a fixed offset in ram there is a tradeoff between scaleability and memory usage. And I really don't see a practical way to fix that. In the normal case of increasing offsets going to increasingly higher addresses in ram the the memory overhead actually becomes a constant. This is because you can overwrite memory that you have already loaded to it's final location. Eric |