qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user: use realpath for emulation dir path


From: Paul Bolle
Subject: Re: [Qemu-devel] [PATCH] linux-user: use realpath for emulation dir paths
Date: Fri, 04 Dec 2009 11:37:44 +0100

On Fri, 2009-12-04 at 11:00 +0100, Arnaud Patard wrote:
> Riku Voipio <address@hidden> writes:
> > On Fri, Oct 02, 2009 at 02:25:36PM +0200, Paul Bolle wrote:
> >> Note that I have some reservations about the current init_paths() and
> >> path() code:
> >> - their names seem to confusing. Maybe those should be init_base()and
> >> base() or something similar;
> >> - why does init_paths() copy all filenames in the emulation dir (at
> >> least, that what it seems to do)? Try something silly like
> >> "-L /home/../" to see what I mean ...
> >> - and why does path() return the original filename if that file isn't
> >> found in the emulation dir? That looks like a nice source for confusing
> >> behavior or crashes, as that means an identical named file (but using 
> >> the regular root) will then be used.
> >
> > Yeah, all that is a big mess and should be cleaned up. At the moment it
> > is all too easy to get init_paths to recurse forever..
> 
> fwiw, it should not be hard to prevent this dead loop. I have
> somewhere a patch avoiding going into /dev,/proc and it cured the
> problem. Of course, there may be some other places leading to deadloop
> but at least avoiding /dev and /proc would be a good start if one
> really wants to fix that.

It's been two months, so I have forgotten most details here, but why is
the init_path() step actually needed? Can't path() simply prepend the
name of emulation dir, if any, and return that (possibly unaltered)
path?

I guess the original path must be altered too (ie, it should point to
the newly created path and the original string should be freed). Can't
that be done reliably?


Paul





reply via email to

[Prev in Thread] Current Thread [Next in Thread]