linux-kernel - Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 1 Jan 2024 11:48:25 -0600
From: Rob Landley <rob@...dley.net>
To: Askar Safin <safinaskar@...il.com>
Cc: Stefan Berger <stefanb@...ux.ibm.com>, gregkh@...uxfoundation.org,
 initramfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org, zohar@...ux.ibm.com
Subject: Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is
 given

On 12/30/23 18:46, Askar Safin wrote:
> On Sat, Dec 30, 2023 at 8:01 PM Rob Landley <rob@...dley.net> wrote:
>> You want to add a new capability requiring a new build dependency in the
> 
> Rob, who are you telling this to? To Stefan? It seems he doesn't
> propose any further changes. *I* did propose changes (i. e. adding
> rdrootfstype=), and I already wrote that I will not pursue further

I was trying to make sure we can support the motivating use case, and that there
aren't any actual blockers with the current API.

I don't ask things like "Do I have that right?" sarcastically: I am periodically
wrong about stuff. You all know your use case(s) better than I do, and I may not
have understood your attempt to communicate it to me.

I get a bit exasperated at "this thing that's been there for 10 years could
instead have been like this" because I think changing established kernel api is
_conceptually_ expensive (either we broke the old one or now we have to support
two), but "I still can't figure out how to make X work" means somebody still
needs help (up to and including actually motivating an API change, but more
commonly some userspace design work and/or a documentation update).

Thank you for clarifying. It looks like we're good here for the moment.

Rob