Date:        Fri, 22 Nov 2002 09:27:40 +0100
    From:        Martin Husemann <martin@duskware.de>
    Message-ID:  <20021122082740.GD416@drowsy.duskware.de>

  | Only one file,

Which means the file is altered, which means that you can no longer easily 
check that the file you're running is identical with the distribution copy.

I much prefer the "file on the side" method, provided the file goes in /var
and not /usr (/usr is, or should be able to be, read only - I mount it that
way all the time, and would prefer to avoid even more null mounts to provide
the few odd necessary writable pieces - currently all required by X).

Jun-Yong ...

  | My proposal is also completely optional.

per file (executable) or just on/off big switch?   I'd prefer the former.
That is, the vast majority of programs aren't run enough, and don't cost
enough to dynamically link, that it really isn't worth the effort dealing
with them.   I'd like to just turn on this cache for the few files that are
used enough,a nd cost enough, that there would be a real gain.   If it is
per file, how is it controlled?

I had a half thought out idea of something similar, but just keeping the
linked binary in swap space (in virtual memory) so it would be re-bound once,
at least, each boot (and perhaps more often, using weighted LRU (weighted by
size) to discard bindings and avoid using too much VM) which I had expected
might be controlled by the 't' bit on the executable (with that being passed
to ld.elf_so - and it telling the kernel to preserve a copy of the image,
by making all pages copy on write, keeping the original untouched, in a
cache, ready for next time - if the kernel found such a thing in this new
cache, it would just skip ld.elf_so completely, and run the copy instead).

kre