From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lbkVo-00073D-Bx for mharc-grub-devel@gnu.org; Wed, 28 Apr 2021 09:45:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbkVk-0006zn-Df for grub-devel@gnu.org; Wed, 28 Apr 2021 09:45:54 -0400 Received: from dibed.net-space.pl ([84.10.22.86]:33845) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:192) (Exim 4.90_1) (envelope-from ) id 1lbkVi-0001Ma-Ah for grub-devel@gnu.org; Wed, 28 Apr 2021 09:45:52 -0400 Received: from router-fw.i.net-space.pl ([192.168.52.1]:42704 "EHLO tomti.i.net-space.pl") by router-fw-old.i.net-space.pl with ESMTP id S2096085AbhD1Npj (ORCPT ); Wed, 28 Apr 2021 15:45:39 +0200 X-Comment: RFC 2476 MSA function at dibed.net-space.pl logged sender identity as: dkiper Date: Wed, 28 Apr 2021 15:45:36 +0200 From: Daniel Kiper To: Colin Watson , Michael Chang Cc: grub-devel@gnu.org, Glenn Washburn , Marco A Benatto , Javier Martinez Canillas Subject: Re: [PATCH v2] i386-pc: build verifiers API as module Message-ID: <20210428134536.5ohkx3f5lqwecqvm@tomti.i.net-space.pl> References: <20210322161626.GN26923@riva.ucam.org> <20210322151906.5946fb23@crass-HP-ZBook-15-G2> <20210322204527.GO26923@riva.ucam.org> <20210323163312.xmhzcsxfqovgm27y@tomti.i.net-space.pl> <20210324044452.GB4620@mercury> <20210326170101.bjup2bcu3trlyh6v@tomti.i.net-space.pl> <20210412131553.xd7qejacnadm2nwn@tomti.i.net-space.pl> <20210413041302.GA24779@mercury> <20210414132235.pr3jl32qb3op2e57@tomti.i.net-space.pl> <20210420034909.GA13843@mercury> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210420034909.GA13843@mercury> User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: pass client-ip=84.10.22.86; envelope-from=dkiper@net-space.pl; helo=dibed.net-space.pl X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 13:45:54 -0000 Hi all, On Tue, Apr 20, 2021 at 11:49:09AM +0800, Michael Chang via Grub-devel wrote: > On Wed, Apr 14, 2021 at 03:22:35PM +0200, Daniel Kiper wrote: > > On Tue, Apr 13, 2021 at 12:13:02PM +0800, Michael Chang via Grub-devel wrote: > > > On Mon, Apr 12, 2021 at 03:15:53PM +0200, Daniel Kiper wrote: > > > > On Fri, Mar 26, 2021 at 06:01:01PM +0100, Daniel Kiper wrote: > > > > > On Wed, Mar 24, 2021 at 12:44:52PM +0800, Michael Chang via Grub-devel wrote: > > > > > > On Tue, Mar 23, 2021 at 05:33:12PM +0100, Daniel Kiper wrote: > > > > > > > On Mon, Mar 22, 2021 at 08:45:27PM +0000, Colin Watson wrote: > > > > > > [snip] > > > > > > > > After some thinking it seems to me we can do this. I can take "i386-pc: > > > > > build verifiers API as module", "kern/misc: Move grub_printf_fmt_check > > > > > to gfxmenu" and similar patches into 2.06. I will revert after the > > > > > release all the patches which adds ifdefery or make code ugly and do not > > > > > benefit other platforms than i386-pc. This way you will have support for > > > > > small MBR gaps in 2.06 and I will have clean code after 2.06 release. > > > > > > > > > > Does it work for you guys? > > > > > > > > Does anybody care? > > > > > > Could you please consider not reverting them ? For me it is worse than > > > keeping them as distribution specific patch, as we will have a hard time > > > to explain what's going on when we have to reintroduce them in rebasing > > > to commits later to 2.06. > > > > Colin, Michael, how long are you going to support small MBR gaps? > > Sorry I may not be able to provide right answer. I think the problem has > two folds. > > 1. For the development code stream, especially upstream git. We wanted > to stop short mbr gap support for good. There are good reasons for doing > so. (clean code, free to add new features and so on). I thought about the issue quite long time and finally decided to drop official small MBR gap support from the GRUB upstream starting from now. This was not easy decision. However, as I can see less and less people care about small MBR gaps setups. So, I think it makes less and less sense to keep such strong size constraints on the core.img size for all architectures and platforms. Especially if these constraints make the GRUB development more complicated and weird. > 2. For the maintenace code stream, especially downstream branch with > long term service support for years. We cherry-picked patch only for bug > and security fixes. The long life span may have building up quite some > number of setup running on short mbr gap. Ideally we didn't have to > worry about that, as long as no new feature would be allowed to add up > the core size. But things changed after this very high priority boothole > security fixes that contributed too much size growth and may have very > bad consequence. We have no choice but to manage that or the result is > out of our control. > > If we are seeking for the common ground. For me it would be that the > size still matters for bug and security fixes as that would be the > material interested by LTSS backport. For new features, it is nice to > have. But that still depends on the feedback as different distrubution > may see different needs. I think distros which care about small MBR gaps setups may build and share common set of patches making that support possible for them. I am also happy to make their life a bit easier by taking the patches which reduce core.img size and still are valuable optimizations for other architectures and platforms. Additionally, I am OK with adding to the GRUB documentation common instructions for migrating from the small MBR gaps to different partitioning schemes which does not impose so strong limitations on the core.img size. One take away for me from this situation is that I should do better job with communicating my plans in the future. > Finally, thanks your patience for this issue. You are welcome! Sorry for the inconvenience... Daniel