Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220430090518.3127980-1-chenhuacai@loongson.cn>
 <20220430090518.3127980-21-chenhuacai@loongson.cn> <CAK8P3a2SPTLLrZtSz0LT0LqMpq4SKCScD4vLvr+DJn+u5W_CdA@mail.gmail.com>
 <CAMj1kXEDpJwLDD4ZGLwzdo1KcJG_90iD9MnBVamCK06YKF7BdA@mail.gmail.com>
 <CAAhV-H4eR5YvhABp9L4FBmofWwH+XM3V_nOjatQTV_M7Gihs7g@mail.gmail.com>
 <CAMj1kXFD8_CuijJFgQbrxvY4MVBLmKQKFKmYhD1NBFLn3v=+FQ@mail.gmail.com> <a6afaa3f-cb9f-2086-0e02-5ec21ba535d4@xen0n.name>
In-Reply-To: <a6afaa3f-cb9f-2086-0e02-5ec21ba535d4@xen0n.name>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Fri, 6 May 2022 13:41:36 +0200
Message-ID: <CAK8P3a0xuh1aAM7iwE-jiBbR-OOF5YVfhmU0Nygbpviso3tmbQ@mail.gmail.com>
Subject: Re: [PATCH V9 20/24] LoongArch: Add efistub booting support
To:     WANG Xuerui <kernel@xen0n.name>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Huacai Chen <chenhuacai@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Airlie <airlied@linux.ie>,
        Jonathan Corbet <corbet@lwn.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Xuefeng Li <lixuefeng@loongson.cn>,
        Yanteng Si <siyanteng@loongson.cn>,
        Guo Ren <guoren@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, May 6, 2022 at 1:26 PM WANG Xuerui <kernel@xen0n.name> wrote:
> On 5/6/22 16:14, Ard Biesheuvel wrote:

> Or is there compatibility at all?
>
> It turns out that this port is already incompatible with shipped
> systems, in other ways, at least since the March revision or so.

I think we can treat user space compatibility separately from firmware
compatibility.

> So, in effect, this port is starting from scratch, and taking the chance
> to fix early mistakes and oversights all over; hence my opinion is,
> better do the Right Thing (tm) and give the generic codepath a chance.
>
> For the Loongson devs: at least, declare the struct boot_params flow
> deprecated from day one, then work to eliminate it from future products,
> if you really don't want to delay merging even further (it's already
> unlikely to land in 5.19, given the discussion happening in LKML [3]).
> It's not embarrassing to admit mistakes; we all make mistakes, and
> what's important is to learn from them so we don't collectively repeat
> ourselves.

Agreed. I think there can be limited compatibility support for old
firmware though, at least to help with the migration: As long as
the interface between grub and linux has a proper definition following
the normal UEFI standard, there can be both a modern grub
that is booted using the same protocol and a backwards-compatible
grub that can be booted from existing firmware and that is able
to boot the kernel.

The compatibility version of grub can be retired after the firmware
itself is able to speak the normal boot protocol.

       Arnd