Hi, Le mar. 17 nov. 2020 à 05:35, Victor Kamensky <victor.kamens...@gmail.com> a écrit :
> Hi Yann and Richard, > > On Fri, Nov 13, 2020 at 5:59 AM Yann Dirson <yann.dir...@blade-group.com> > wrote: > > > > Oh I did not notice, shouldn't we be discussing this on-list ? > > Very sorry about this. I did not notice that I've unintentionally removed > the mailing list. > Added it back. > > I see that Richard added your patches to master-next. But I don't think > they should be > merged "as is". IMO we need to work more on them. > > Richard, could you please hold off merging them? > > Other thing that AUT done automatic upgrade to systemtap-4.4 and Zang have > sent patch > for it. IMO let's first merge 4.4 while we sort out what part of this > series should go in. > > Let's go about slowly one issue at a time. > > More responses inline. > > > Another question: I can't really see what it brings, to be able to > disable the "monitor" feature. > > What should we write about this feature ? > > > > Le ven. 13 nov. 2020 à 11:57, Yann Dirson <yann.dir...@blade-group.com> > a écrit : > >> > >> > >> > >> Le jeu. 12 nov. 2020 à 21:11, Victor Kamensky < > victor.kamens...@gmail.com> a écrit : > >>> > >>> Hi Yann, > >>> > >>> I am not sure that I understand purpose of the series. > >> > >> > >> The goal was to be able to include a precompiled probe in a readonly > image, and to get > >> it loaded during execution of a boot script (I was hunting a but that > only shows during > >> target startup). > > It is an interesting feature, do you plan to merge precompiled probes in > production image, or > you want to add one for some debug case. > The idea is to be able to get probes in production images, at least shipped to select customers or even just internal users when we need to hunt for particulary rare problems, and having to modify the build chain makes things quite more painful (we use the same image signing and publication process for all). > If it is latter one probably there are ways to do > it just by adding file built crosstap just as additional payload to the > image. > I'm curious how would you do that with standard tools ? One coworker wrote for this kind of test an unsquashfs-stuff-resquashfs that kinda does this kind of work In developper case I personally deal with it by stopping system boot very > early i.e using > systemd "emergency" parameter passed as kernel boot option, dropping into > the shell > mounting some storage with precompiled probe, copy and activate probe and > exiting > emergency shell. > That would not have worked for the particular problem for which I worked on this, where the bug did not appear on every boot, and is probably linked to a race condition exacerbated by loading times from squashfs :) Also if we do with supporting such a feature one should be able to build > probe not only for > kernel but for the whole user-land. Does your proposed patch series > support probes for user-land > too? If so, how do you do that: chicken and egg problem - to build > user-land probe one need > complete sysroot of target, but since probe should be include in the > image, how do one > build sysroot first. > I admit I have not started to look into userland probes, as the system probe I deployed had already given valuable information. >> > >> It happens that I had not discovered the crosstap tool when I started > this, but it does not seem > >> to help much in my use-case. > >> > >> My approach was naturally integrated into the build, packaging the > cross-build of the .stp module, > >> finally giving birth to the systemtap.bbclass you can find in v1 of > this series (which I'm here postponing > >> to a further series). > >> > >> I also wanted to avoid installing unused stuff on target, and starting > disabling some PACKAGECONFIG > >> items, finding disabling some caused problems. > >> > >>> > >>> The current way to include SystemTap minimal runtime only into target > image > >>> that allow to run compiled on host scripts is to use > >>> > >>> PACKAGECONFIG_pn-systemtap = openembedded-core@lists.openembedded.org > "monitor" > > >> > >> > >> OK, for some reason I had missed that it does indeed achieve that. > Maybe we should add more doc about that. > >> > >> The split of a -runtime package, however, allows to still build the > "translator" part, not have it installed in the image > >> shipped on product, but still have the ability to install it from the > feed while developing, should someone prefer > >> this to cross-building the probes. Not a big deal if you prefer not to > do that however, my own use-case would be > >> covered by the PACKAGECONFIG="monitor". > > Yes, I was thinking about this use case as well. But it is quite esoteric > for OE. Furthermore, > it kind of contradicts current PACKAGECONFIG structure. If we want to go > this route we need > to reshuffle the whole thing in a different way. I.e either use > PACKAGECONFIG to > control the content systemtap package or use subpackages. Using both looks > a bit convoluted. > This would make sense, yes. > >> > >> But as state above it does not build on master/gatesgarth/dunfell > because of the problem fixed by the "fix install when python3-probes is > disabled in PACKAGECONFIG" > >> patch in this series. > >> > >> Furthermore, this minimal package with just runtime support still pulls > python3-core without a need for it. > >> This is coming from "inherit distutils3-base", and we should probably > not pull this one unless "python3-probes" > >> is enabled. I had missed this one, will add another patch for this. > >> > >> BTW, does it make any sense to select "python3-probes" but not > "translator" ? > > I don't quite yet follow this issue and need to play more before answering > it. Could you > please post separate patch only for this? > Sending in a few minutes after rebasing (just saw Richard's email) > Thanks, > Victor > > > On Fri, Nov 13, 2020 at 5:59 AM Yann Dirson <yann.dir...@blade-group.com> > wrote: > >> Oh I did not notice, shouldn't we be discussing this on-list ? >> >> Another question: I can't really see what it brings, to be able to >> disable the "monitor" feature. >> What should we write about this feature ? >> >> Le ven. 13 nov. 2020 à 11:57, Yann Dirson <yann.dir...@blade-group.com> >> a écrit : >> >>> >>> >>> Le jeu. 12 nov. 2020 à 21:11, Victor Kamensky < >>> victor.kamens...@gmail.com> a écrit : >>> >>>> Hi Yann, >>>> >>>> I am not sure that I understand purpose of the series. >>>> >>> >>> The goal was to be able to include a precompiled probe in a readonly >>> image, and to get >>> it loaded during execution of a boot script (I was hunting a but that >>> only shows during >>> target startup). >>> >>> It happens that I had not discovered the crosstap tool when I started >>> this, but it does not seem >>> to help much in my use-case. >>> >>> My approach was naturally integrated into the build, packaging the >>> cross-build of the .stp module, >>> finally giving birth to the systemtap.bbclass you can find in v1 of this >>> series (which I'm here postponing >>> to a further series). >>> >>> I also wanted to avoid installing unused stuff on target, and starting >>> disabling some PACKAGECONFIG >>> items, finding disabling some caused problems. >>> >>> >>>> The current way to include SystemTap minimal runtime only into target >>>> image >>>> that allow to run compiled on host scripts is to use >>>> >>>> PACKAGECONFIG_pn-systemtap = "monitor" >>>> >>> >>> OK, for some reason I had missed that it does indeed achieve that. >>> Maybe we should add more doc about that. >>> >>> The split of a -runtime package, however, allows to still build the >>> "translator" part, not have it installed in the image >>> shipped on product, but still have the ability to install it from the >>> feed while developing, should someone prefer >>> this to cross-building the probes. Not a big deal if you prefer not to >>> do that however, my own use-case would be >>> covered by the PACKAGECONFIG="monitor". >>> >>> But as state above it does not build on master/gatesgarth/dunfell >>> because of the problem fixed by the "fix install when python3-probes is >>> disabled in PACKAGECONFIG" >>> patch in this series. >>> >>> Furthermore, this minimal package with just runtime support still pulls >>> python3-core without a need for it. >>> This is coming from "inherit distutils3-base", and we should probably >>> not pull this one unless "python3-probes" >>> is enabled. I had missed this one, will add another patch for this. >>> >>> BTW, does it make any sense to select "python3-probes" but not >>> "translator" ? >>> >>> Best regards, >>> -- >>> Yann >>> >>> >>>> in your local conf/local.conf file or add proper bbappend where only >>>> monitor feature would be enabled for systemtap package. >>>> >>>> That is mentioned at in crosstap script help >>>> >>>> http://git.openembedded.org/openembedded-core/tree/scripts/crosstap#n370 >>>> >>>> Thanks, >>>> Victor >>>> >>>> On Thu, Nov 12, 2020 at 9:28 AM Yann Dirson < >>>> yann.dir...@blade-group.com> wrote: >>>> > >>>> > From: Yann Dirson <y...@blade-group.com> >>>> > >>>> > The goal of this series is to make it possible to run compiled >>>> > systemtap probes on the target without all the tools otherwise >>>> > necessary to compile them. >>>> > >>>> > This series also includes unrelated fixes to the systemtap packaging, >>>> > on which I stumbled while on the main subject. >>>> > >>>> > Changes from v1: >>>> > >>>> > * the last 3 patches, whole goal is to provide a systemtap.bbclass >>>> > will be rerolled into another series later and were removed >>>> > * the "split runtime material" changes the runtime test to use the >>>> > smaller runtime package >>>> > >>>> > >>>> > Yann Dirson (5): >>>> > systemtap: split examples and python scripts out of main package >>>> > systemtap: remove extra dependencies >>>> > systemtap: clarify the relation between exporter and python3-probes >>>> > feature >>>> > systemtap: fix install when python3-probes is disabled in >>>> > PACKAGECONFIG >>>> > systemtap: split runtime material in its own package >>>> > >>>> > meta/lib/oeqa/selftest/cases/runtime_test.py | 2 +- >>>> > .../recipes-kernel/systemtap/systemtap_git.bb | 38 >>>> ++++++++++++++++--- >>>> > 2 files changed, 33 insertions(+), 7 deletions(-) >>>> > >>>> > -- >>>> > 2.28.0 >>>> > >>>> > >>>> > >>>> > >>>> >>> >>> >>> -- >>> Yann Dirson <y...@blade-group.com> >>> Blade / Shadow -- http://shadow.tech >>> >>> >> >> -- >> Yann Dirson <y...@blade-group.com> >> Blade / Shadow -- http://shadow.tech >> >> -- Yann Dirson <y...@blade-group.com> Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144690): https://lists.openembedded.org/g/openembedded-core/message/144690 Mute This Topic: https://lists.openembedded.org/mt/78211639/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
