> Hmmm, guess this might make some of my patches to milo (but not all)
> obsolete. :-(.
No, don't worry. My changes don't affect the basic way Milo
works, it just avoids tons of seeks during kernel load.
> Also, this assumes that you can load the kernel at the right place in
> physical memory. The location for the Deskstation rpc44 is different
> than other machines, I fear, due to the 640K low memory limit. I also
> think that it may be wasteful of space since it will keep the kernel
> symbols in memory if you aren't careful. How does the kernel get
> relocated to its right place? Are you copying it down from high
> memory where the malloc returns memory?
Yes, the kernel including all symbols etc. is loaded to high memory
first and then copied down to it's final location by using the
same and unchanged functions as before. Useless kernel symbols
are free'd as soon the kernel starts. They occupy memory only while
Milo is running. Actually, as it was before.
> Anyway, despite these misgivings (which are likely just
> misunderstandings on my part), I think this is a great idea! This
> would mean that we could put the data decompression into MILO itself
> with very little effort if we load the kernel high enough. The whole
> thing could be read in off disk (which should be even faster, I would
> imagine) and then decompressed into the right location. I'm not sure
> how that would impact MILO's load time, since it would have to be
> bigger by a small amount.
You're right. The kernel could be compressed completely which certainly
makes a difference when you have lots of symbols. BTW, for source
level debugging I boot a mostly stripped kernel and use the unstripped
(3 Meg) kernel only for GDB. I couldn't write it on a floppy anyway :-)
> I'd love to be able to have the same load address for all machines,
> but fear that we might not be able to do that easily. Well, we could
> make it 0x80010000 on all machines, and have Linux be smart enough to
> put either the low 640K or the low 1M of memory depending on the
> machine into its free pool of memory. This sounds like the most
> portible way to cope with the problem...
Hmmm. That would work, but actually I don't like this unnecessary
memory fragmentation. But if the other's agree...