Looking for a suitable meta/recipe path to place the QuickBoot (Early audio, camera, display) code optimizations

[ctheegal]

QuickBoot achieves early boot of critical services (Audio, Camera, Display) which reduces the 'time-to-first-perception' for end users:

• Explicit Kernel Module Pre-loading — Modules are pre-loaded in dependency order via modules-load.d during systemd-modules-load.service, bypassing slow udev coldplug.

• Event-Driven Service Activation via udev — Custom udev rules trigger services instantly on device node creation (e.g., controlC0, video0, card0), eliminating polling delays.

• Minimal systemd Dependencies (DefaultDependencies=no) — Removes implicit ordering after sysinit.target/basic.target, allowing services to start in parallel as soon as hardware is ready.

This is a good product differentiator! Need your inputs regarding where (which recipe?) to place this code.

Refer the code in our internal repo: https://github.com/ctheegal/quickboot to understand more about the design and implementation.

[ricardosalveti]

I don't think we need these changes as part of an extra layer, my expectation would be to have them proposed at meta-qcom-distro, and control their usage based a specific distro feature associated with fast boot.

That way we can review the changes independently.

[ctheegal]

Ricardo Salveti (@ricardosalveti) — Thanks for the clear direction! Fully agree with the approach.

We'll move the QuickBoot recipes into meta-qcom-distro under recipes-earlyboot/
(or pls name any existing recipe which you prefer) and gate them behind a 'earlyboot' DISTRO_FEATURE
so they are opt-in and don't affect standard builds.

This way:

• No extra layer needed
• Changes are reviewable independently in meta-qcom-distro
• Teams can enable earlyboot by adding it to DISTRO_FEATURES

Currently, refactoring the code and validating on other targets. We'll send the patches for review shortly. Let us know if you have a preference
on the recipe directory name or the distro feature flag name.

[ricardosalveti]

I would suggest fastboot or quickboot instead of earlyboot as early could have a different meaning, but get your initial changes and propose for an initial review, then we can discuss the best way to land the changes.