[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MiNT 1.10 re-sync
Stephen Usher writes:
> >Michael Hohmuth writes:
> >> > 6. and now the sticky text/fragmentation megapatch... does a few things:
> >> > . execv..() frees the old process memory before allocating the new ones,
> >> > and so no longer leaves holes in your memory map. this took a few
> >> > ugly hacks but i think its worth it :) the only visible change should
> >> > be when exec'ing a damaged binary the process gets killed, fixing that
> >> > would require reading executables twice.
> >> Well, that's fine with me, but I don't know whether this "non-posixish"
> >> behaviour is tolerable by all others? I guess so... as it effectively
> >> makes "damaged executable" equivalent to "executable crashed immediately
> >> after it has been run".
> Hmm.. I think this is bad as many programs have code after an exec which
> takes alternate action if the exec fails.
well that still works for the usual cases (bad magic, ENOMEM, ENOENT...)
the kill should only happen when the executable header looked ok and the
error is somewhere later in the file. i.e. you need a broken linker,
overwritten blocks, or some filesystem error for this to happen...
> The alternative, of course, is to
> copy the original text elsewhere before loading the new program if the new
> program's text is smaller or the same size as the original program. If the
> exec fails then it can be copied back and the process resumed.
thats another idea but is it worth it? :)
> If the new
> process being exec()ed is larger than the original program (and the memory
> above the current program isn't free) then exec()ing as we do now would be
> no problem.
hmm but you'd still get a hole?
> The only sure way to stop memory fragmentation is to start using paged
> memory management. This, of course, can only be done on the 68030 and above.
> > or whats on systems that demand-page text instead of loading it all at
> >once... do they always check the entire file before?
> >> Opinions?
> > should there be some flag to turn it off? in mint.cnf?
J"urgen Lock / email@example.com / UUCP: ..!uunet!unido!uniol!jelal!nox
PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA