Re: pseudo interaction issue

[Peter Seebach <peter.seebach@windriver.com>]

On Sat, 24 Mar 2012 17:15:15 +0000
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> What puzzles me is we get this value from  envbackup[key] =
> os.environ.get("PSEUDO_PREFIX") so its already not in the environment.
> 
> So basically if we read "PSEUDO_PREFIX" from the environment we get
> nothing. If we unset the value back to being "nothing", things break.

Yes.  This is, of course, obviously impossible.

Hmm.  Well, hmm.  When we start up, we should pick up PSEUDO_PREFIX
from our environment, and during some of the initial client setup, we
should be stashing that value in our stashed values table.  At this
point, so far as I can tell, nothing should ever unset that stashed
value.

On fork(), we don't change anything until we're in the client side of
the fork, but that setup should happen in the same address space, with
the values still stashed.

I did find one other thing, though, which worries me.  I added a
popen() wrapper, and the thing is.  We're calling popen() with the
"antimagic" bit set (the one that suppresses all the wrappers).

Which would cause all sorts of problems, and I can't figure out how
it'd be happening.  So my new theory:

* There's something specific causing us to end up invoking popen()
  with the antimagic bit set.  This is obviously impossible.
* But that means that, even if we trap other syscalls made by popen(),
  we won't be doing wrappers or fixups.
* And that could expose problems to do with PSEUDO_PREFIX getting
  unset unexpectedly.

So I think adding it to BB_ENV_EXTRAWHITE will hide this, but it won't
explain how we're getting into a popen() call in antimagic mode.
(Antimagic is the internal thing pseudo uses while trying to do
client/server communications.  Pretty sure it never calls popen.)

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.