| Message ID | 20251126090202.3091051-5-itrue@emlix.com |
|---|---|
| Headers | show |
| Series | linux-custom: add linux-tools package and perf | expand |
Hi Isaac, On Wed, 2025-11-26 at 09:59 +0100, 'Isaac True' via isar-users wrote: > Modify the linux-custom recipe to additionally generate a linux-tools > package, build the perf binary, and add this binary to the new package. > This is useful for profiling application and kernel performance on > targets. > > Isaac True (3): > linux-custom: add linux-tools package > linux-custom: build perf and add it to linux-tools > doc: custom_kernel: add perf and linux-tools Patch ordering: Patch 1 already adds the new package to PROVIDES while building the package comes later with patch 2. That looks inconsistent. I would vote for merging patch 1 and 2. How long does it take to build that additional package? That additional (and maybe unneeded) packet is being build unconditionally, right? As kernel builds are normally compute intense that might matter for some users. Should we better hide that new "feature" / packet behind a feature flag / recipe variable? Best regards, Florian
Hi, > Patch ordering: > Patch 1 already adds the new package to PROVIDES while building the > package comes later with patch 2. That looks inconsistent. > > I would vote for merging patch 1 and 2. Sure, that makes sense. I can do that. > How long does it take to build that additional package? That additional > (and maybe unneeded) packet is being build unconditionally, right? As > kernel builds are normally compute intense that might matter for some > users. > > Should we better hide that new "feature" / packet behind a feature flag > / recipe variable? On my relatively slow laptop it adds about 30s of build time. Relatively minor in the context of a kernel build, but could still be worth hiding it behind a feature flag for people that don't want it. Thanks for the feedback, I'll work on a v2.
On Wed, 2025-11-26 at 10:59 +0100, Isaac True wrote: > Hi, > > > Patch ordering: > > Patch 1 already adds the new package to PROVIDES while building the > > package comes later with patch 2. That looks inconsistent. > > > > I would vote for merging patch 1 and 2. > > Sure, that makes sense. I can do that. > > > How long does it take to build that additional package? That additional > > (and maybe unneeded) packet is being build unconditionally, right? As > > kernel builds are normally compute intense that might matter for some > > users. > > > > Should we better hide that new "feature" / packet behind a feature flag > > / recipe variable? > > On my relatively slow laptop it adds about 30s of build time. Relatively > minor in the context of a kernel build, but could still be worth hiding > it behind a feature flag for people that don't want it. The way to model that would be a build profile (DEB_BUILD_PROFILES) as it seems. I'm still not sure if that is really necessary. As that could be done quite easily (as it seems) we can also postpone that and wait if it becomes necessary. > > Thanks for the feedback, I'll work on a v2. > > -- > Isaac True > emlix GmbH > Headquarters: Berliner Str. 12, 37073 Göttingen, Germany > Phone +49 (0)551 30664-0, e-mail info@emlix.com > District Court of Göttingen, Registry Number HR B 3160 > Managing Directors: Heike Jordan, Dr. Uwe Kracke > VAT ID No. DE 205 198 055 > Office Berlin: Panoramastr. 1, 10178 Berlin, Germany > Office Bonn: Bachstr. 6, 53115 Bonn, Germany > Office München: Am Knie 16, 81241 München, Germany > http://www.emlix.com > > emlix - your embedded Linux partner
On 26.11.25 09:59, 'Isaac True' via isar-users wrote: > Modify the linux-custom recipe to additionally generate a linux-tools > package, build the perf binary, and add this binary to the new package. > This is useful for profiling application and kernel performance on > targets. > > Isaac True (3): > linux-custom: add linux-tools package > linux-custom: build perf and add it to linux-tools > doc: custom_kernel: add perf and linux-tools > Please make them opt-in build profiles. Normally, you neither need nor want these deviations from the official Debian packages, even more if your custom kernel should be older than what Debian delivers. Jan