qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] util: Fix QEMU_LD_PREFIX endless loop


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC] util: Fix QEMU_LD_PREFIX endless loop
Date: Tue, 19 Jan 2016 18:15:33 +0000

On 15 January 2016 at 18:15, Richard Henderson <address@hidden> wrote:
> On 01/15/2016 09:53 AM, Peter Maydell wrote:
>>> @@ -58,7 +58,7 @@ static struct pathelem *new_entry(const char *root,
>>>  #if defined(DT_DIR) && defined(DT_UNKNOWN) && defined(DT_LNK)
>>>  # define dirent_type(dirent) ((dirent)->d_type)
>>>  # define is_dir_maybe(type) \
>>> -    ((type) == DT_DIR || (type) == DT_UNKNOWN || (type) == DT_LNK)
>>> +    ((type) == DT_DIR || (type) == DT_UNKNOWN)
>>>  #else
>>>  # define dirent_type(dirent) (1)
>>>  # define is_dir_maybe(type)  (type)
>>> --
>>> 2.5.0
>>
>> This change would be essentially reverting commit 338d80dd353c50b63,
>> which specifically added support for symbolic links in the directory
>> structure. So if we applied it we'd be regressing on the problem
>> that that change was meant to fix.
>>
>> Richard, git says that commit was one of yours :-)
>
> Because gcc and qemu have different names for their sysroot trees, and in my
> disks, gcc is the "master".  So I normally have
>
>    .../qemu/run/qemu-alpha -> .../gcc/run-cross/alphaev67-linux/sys-root
>    .../qemu/run/qemu-arm -> .../gcc/run-cross/arm-linux-gnueabi/sys-root
>    .../qemu/run/qemu-sparc -> .../gcc/run-cross/sparc64-linux/sys-root
>    .../qemu/run/qemu-sparc64 -> .../gcc/run-cross/sparc64-linux/sys-root
>
> The DT_LNK is required for traversing even the first link.

Right. So the path.c code is definitely buggy, but this patch
isn't the right way to fix it. It really doesn't behave
sensibly if you point it at a full root fs, but lots of people
want to do that, so it would be nice if it worked...

I think the underlying thing the code is trying to do is
create a sort of union-mount of the real root filesystem and
the directory you point at with -L. We need to do that in a way
that doesn't insist on scanning everything in the -L directory
on startup.

thanks
-- PMM



reply via email to

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