On Fri, Nov 22, 2002 at 08:52:40PM +1100, Robert Elz wrote:
>     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).

I like both, but some people don't like "file on the side" method for
security reasons. I'll be back with the subject "Why security doesn't matter"
sooner or later. ;-)

> 
> 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?

Per-file switch can be implemented by filling .cksum (renamed from .csum
for consitency with the name of cksum(1)) with FFFFFF..FFFFFF. System-wide
switch still can be turned on/off by setting/unsetting LD_PREBIND
environment variable. 

> 
> 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).

A kind of "hibernation"?

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>