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. 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. 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. 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. >> >> 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. >> >> 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? 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 > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144678): https://lists.openembedded.org/g/openembedded-core/message/144678 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] -=-=-=-=-=-=-=-=-=-=-=-
