From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8F82C44508 for ; Tue, 14 Jul 2026 16:35:07 +0000 (UTC) Subject: Re: [PATCH] memory-control: add recipe and bbclass for cgroup v2 memory limiting To: openembedded-core@lists.openembedded.org From: "Ishaan Desai" X-Originating-Location: New York, US (129.41.86.2) X-Originating-Platform: Mac Safari 26.5 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 14 Jul 2026 09:35:06 -0700 References: <20260713185154.4171585-1-Ishaan.Desai@ibm.com> In-Reply-To: Message-ID: <777420.1784046906500517885@lists.openembedded.org> Content-Type: multipart/alternative; boundary="AyL4ESOcSNx21YF5LYS4" List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 14 Jul 2026 16:35:07 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/240900 --AyL4ESOcSNx21YF5LYS4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi everyone, The bbclass is intentional. The main use case is for other recipes to inher= it it and set a memory limit for their own service at build time. An .inc f= ile would require an explicit require and manual wiring of the do_install p= ostfunc in every recipe that uses the memory-control tool. The bbclass enca= psulates that cleanly and follows the OE-Core pattern for cross-recipe func= tionality. The memory-control recipe itself is just the runtime companion, = which the bbclass pulls in as an RDEPEND. The motivation comes from embedded/constrained platforms, specifically Open= BMC, where per-service memory limits via cgroup v2 are a common requirement= . Putting this in OE-Core makes it available to any layer without duplicati= ng the implementation, and the pattern of baking systemd drop-ins at build = time is broadly useful beyond any platform. I'm committed to maintaining this recipe and bbclass going forward, and I'v= e added myself to maintainers.inc. If the consensus is that this is too nic= he for OE-Core and belongs in a more specific layer, I'm open to that feedb= ack. Thanks, Ishaan Desai ** --AyL4ESOcSNx21YF5LYS4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

The bbclass is intentional.= The main use case is for other recipes to inherit it and set a memory limi= t for their own service at build time. An .inc file would require an explic= it require and manual wiring of the do_install postfunc in every recipe tha= t uses the memory-control tool. The bbclass encapsulates that cleanly and f= ollows the OE-Core pattern for cross-recipe functionality. The memory-contr= ol recipe itself is just the runtime companion, which the bbclass pulls in = as an RDEPEND.

The motivation comes from e= mbedded/constrained platforms, specifically OpenBMC, where per-service memo= ry limits via cgroup v2 are a common requirement. Putting this in OE-Core m= akes it available to any layer without duplicating the implementation, and = the pattern of baking systemd drop-ins at build time is broadly useful beyo= nd any platform.

I'm committed to maintainin= g this recipe and bbclass going forward, and I've added myself to maintaine= rs.inc. If the consensus is that this is too niche for OE-Core and belongs = in a more specific layer, I'm open to that feedback.

Thanks,
Ishaan Desai

--AyL4ESOcSNx21YF5LYS4--