James A. Crippen
Fri Apr 26 01:23:00 2002
John Morrison <email@example.com> writes:
> For e3, I have punted on the ramdisk, and just stuck the band in
> memory, thinking maybe that I would diddle the page table entries to
> point to reorder the load band in place. Turns out I didn't do that
> -- I just use the same code I use on the unix version to read the
> file a byte at a time into a big address space (with physical page
> commitment upon page fault into that space). I intend to go and now
> reclaim the physical pages the load band occupies now after it has
> been read.
That's kind of an odd way to go about it, but I can see why you're
following that way; it's easy. Maybe in the future (you know, when
all good things come to pass) we can change it to something more
> However, before I go in and chainsaw out the (uncompressed)
> zipfile-based ramdisk support from the application support software,
> are there any other things that we might like to put in a ramdisk?
> Other than the load band?
I don't forsee anything upcoming. Perhaps in the far future we may
have ELF shared-object libraries for some things like OpenGL, special
hardware support, etc. But not any time soon.
I would say just to keep the code in your private archive. Rip it out
of E3. If we ever need it then you can go hunting around in your
boxes of old crufty 9-tracks and CD-ROMs to find the necessary.
James A. Crippen <firstname.lastname@example.org> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.