Re: sysroot option handling

[David Smith <dsmith at redhat dot com>]

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