Re: [Patch] Rebase: new switch --ephemeral

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun 19 21:24, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The implementation of -E is a bit lacking, IMHO.
> 
> Fair enough.
> 
> > The description implies that the ephemeral file list gets "also" rebased.
> > So I take it that there are two lists of files, the ones which get
> > rebased and are written back into the DB, and the ephemeral ones which
> > get rebased but are not written back.
> 
> The unwritten contract is that an ephemeral rebase can only be done if
> the DB is in a stable state.  But you are right, it is better to enforce
> that.

If you really want -E to be an exclusive option, then what I'm missing
is the enforcement on the command line.  In theory, if you specify the
-E option, neither the -T option should be allowed, nor specifying any
additional files on the command line.  Right now, either the -E or the
-T option will be silently ignored.  Even more puzzeling, if you specify
something like this:

  -E filelist1 -T filelist2 file1 file2...

the -E option will set the global image_ephemeral_flag, but the list of
files will *not* be taken from filelist1, but from filelist2, as well as
from the command line.

> > Another problem is this.  The idea of the DB stuff is to make sure that
> > the DLLs on the system are rebased in a compact way.  Since your
> > ephemeral DLLs are handled exactly like the persistent DLLs in
> > merge_image_info, the ephemeral and persistent DLLs memory addresses
> > will be blended together.  So you generate holes in the memory layout
> > of the persistent DLLs, which is kind of contrary to the idea behind
> > this.
> 
> This only happens if the DB is unstable (I think).  Since I now do not
> touch anything not in the DB, this should be no concern anymore.  It is
> intended that ephemeral DLL use holes in the mapping if they are
> available, otherwise I could just rebase down from the lowest base
> address.

Hmm.

[...time passes...]

The longer I think of it, the more I'm wondering if you really need
the -E option at all.  The question is this:  Why is it a problem to add
ephemeral DLLs to the DB?  And, is the distinction between ephemeral
and persistent DLLs not kind of artificial?  But let's keep the distinction
for the sake of discussion.

In theory you would want the ephemeral DLLs in the DB, too.  After all,
as long as they exist and are in use, they should blend together with
the other, persistent DLLs without colliding with them.  As soon as they
disappear from the disk, the next rebase run will remove them from the
DB as well, and another DLL can take the place (if it fits into the
slot).  The same happens with the persistent DLLs.  If you remove the
package containing cygncurses6.dll, a followup rebase(all) run will
remove the DLL from the DB and it's memory slot is free for reuse.

Given that, I don't see a qualitative difference between the DLLs from the
distro and the DLLs you add manually, even if only for testing purposes.
Ultimately they probably need rebasing, they should not collide with
other DLLs, and they are removed from the DB when you remove them from
the disk.  Just like the so-called persistent DLLs.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat