Re: sysroot option handling

[David Smith <dsmith at redhat dot com>]

Oh, one more thing here.

I was chatting with Frank about this, and I think he's convinced me
that one thing to help in the sysroot code is to always have one. If
the user doesn't specify one, treat that case like "--sysroot=/". That
should hopefully simplify the code a bit (we'd never have to check for
an empty sysroot since it would always have a value).

On Fri, Mar 9, 2018 at 11:35 AM, David Smith <dsmith@redhat.com> wrote:
> Victor,
>
> For testing, we need a solution that can be set up without any user
> intervention and works across all tested architectures. I don't
> believe qemu meets those requirements.
>
> Arkady, a docker container might work, but also wouldn't be available
> on all arch/os combinations.
>
> Victor, I should have spelled out my bind mounts idea more fully. We'd
> bind mount the kernel build tree to a new location (for example), then
> bind mount an empty directory over the old directory location (so
> there'd be no leaks). The advantage this idea has is that it is
> supported on all arch/os combinations, (fairly) easily scriptable, and
> doesn't require extra software.
>
>
> On Fri, Mar 9, 2018 at 12:16 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> I did not read the whole thread - will a Docker container do the trick?
>>
>> On Fri, Mar 9, 2018 at 1:07 AM, Victor Kamensky <kamensky@cisco.com> wrote:
>>> Hi David,
>>>
>>> On Thu, 8 Mar 2018, David Smith wrote:
>>>
>>>> Victor,
>>>> k
>>>> I'm working through your sysroot patches now,
>>>
>>>
>>> I appreciate your time and attention to this!
>>>
>>>> but here's the problem
>>>> we have with this code in general. Someone wanted this feature and the
>>>> work got done. However, we never could figure a way of testing it. So,
>>>> over time the functionality has gotten broken without anyone
>>>> realizing. I'd imagine others have tried it, realized it didn't work
>>>> properly, and abandoned it.
>>>
>>>
>>> I reckon, that is something like this. Although I could not make it
>>> work even when I went to the point when first --sysroot support
>>> was committed, although I might be doing something wrong.
>>>
>>>> I'd love to find a way to test this on a "normal" system (without a
>>>> real sysroot).
>>>
>>>
>>> Real sysroot is not that bad :). If you find time please try
>>> setup I aranged and pointed in my cover letter:
>>>
>>> https://github.com/victorkamensky/systemtap-oe-sysroot-manifest
>>>
>>> Since it uses qemu one can really run it on regular x86 Linux machine,
>>> and inside of qemu one can run full Linux even of different CPU type.
>>> Since it is cross mode, and target qemu Linux does not need to
>>> run SystemTap translator, target limitted performance is not an
>>> issue.
>>>
>>> It is quite fun IMHO, I advise to try it. It also will cover adjacent
>>> testing needs like testing on other CPU types like armv7,
>>> aarch64, ppc, and mips ... I am not sure what you do now to
>>> cover those, Fedora/RedHat does cover some other CPU types but not all
>>> that supported by SystemTap. BTW I did run into several quirks/errors on
>>> different CPU types during my limitted testings, I did not have
>>> time to look at them yet.
>>>
>>> I do work now in parallel on pushing patches as in above setup to
>>> OpenEmbedded, I really care that cross compiled use of systemtap
>>> in OE should be very smooth. I hope when it is accepted more people
>>> will use it. It will give SystemTap --sysroot more coverage. Please
>>> check:
>>>
>>> http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148387.html
>>>
>>> In prinicipal DejaGnu framework that SystemTap uses for testing
>>> can support cross build environment, where compilation happens
>>> on host in cross mode but execution and test runs on target. I
>>> once was sort of somewhat close of this thing working for
>>> SystemTap. But did not follow up on it :(. Please check in your
>>> systemtap git tree "git show 2fbd4ab" (it is on never completed
>>> systemtap-1.6-cisco-patches, just for reference branch). It is
>>> doable but quite a bit of work. I am not ready to commit to repeat
>>> it yet :).
>>>
>>> Note but if one can get there and with combination with qemu machines
>>> both --sysroot and non-x86 CPU testing could be covered.
>>>
>>>> Perhaps set up bind mounts to make it appear that the
>>>> current kernel-devel tree is under a sysroot directory (we did
>>>> something similar for server testing)?
>>>
>>>
>>> The drawback of above approach that host and fake "target sysroot"
>>> are not that different. I.e if one has problem
>>> with --sysroot handling and it bleeds to host instead, if host
>>> binary and DWARF symbols are
>>> the same as on fake sysroot it is hard to notice it, since it would keep
>>> working. For example I specifically choose "mkdir.coreutils" as
>>> my testing target since such binary would not exist on my host.
>>>
>>>> If you've got any ideas here I'd love to hear them.
>>>
>>>
>>> Sorry, I cannot give full solution, but I hope my responses
>>> were somewhat helpful.
>>>
>>> Thanks,
>>> Victor
>>>
>>>
>>>> --
>>>> David Smith
>>>> Associate Manager
>>>> Red Hat
>>>>
>>>
>
>
>
> --
> David Smith
> Associate Manager
> Red Hat



-- 
David Smith
Associate Manager
Red Hat