Re: [PATCH v3 0/7] init: discoverable root partitions

[Vincent Mailhol <mailhol@kernel.org>]

On 10/11/2026 at 17:03, Christian Brauner wrote:
> On Mon, Nov 02, 2026 at 10:29:07PM +0100, Vincent Mailhol wrote:
>> This series adds root discovery directly into the kernel so that people
>> who are not using an initrd can still benefit from it.
> 
> Nothing has changed since
> https://lore.kernel.org/r/20260617-irritation-rollen-wirst-7d636cbfec92@brauner

I replied to your earlier message to explain my position but did not
hear back.

Since v1, I have rewritten the cover letter to better explain why I
think implementing a subset of DPS in the kernel makes a
difference. The relevant paragraph is:

  This is useful for booting a kernel manually, for example from the edk2
  file browser, or recovering from a lost or corrupted bootloader
  configuration without having to supply the correct root= argument or
  load an initrd from the bootloader shell. Finally, it allows systems
  that otherwise need no initrd to discover their root partition through
  DPS without introducing an early userspace environment solely for that
  lookup.

Similarly, I clarified the scope to address your concern about the
complexity of DPS:

  The scope is deliberately limited to block devices that the kernel can
  already mount through the root= parameter. Other DPS features, such as
  setting up LUKS-encrypted partitions, mounting partitions other than
  root or container setup, remain userspace responsibilities, with no
  future plan to implement them in the kernel. The intended usage is
  thus a hybrid approach in which the kernel DPS only mounts the root
  partition and leaves the remaining setup to userspace (either with DPS
  or with a classic fstab), just as it does today when root= specifies
  the root device.

I would appreciate hearing whether these use cases and the limited
scope address your concerns.


Yours sincerely,
Vincent Mailhol