From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 765C6CAC5AE for ; Fri, 26 Sep 2025 16:52:57 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1v2Bfq-0002Yp-B3; Fri, 26 Sep 2025 12:51:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v2Bfo-0002Xy-7y for grub-devel@gnu.org; Fri, 26 Sep 2025 12:51:56 -0400 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1v2Bfi-00076J-UW for grub-devel@gnu.org; Fri, 26 Sep 2025 12:51:55 -0400 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6228de280a4so4447378a12.2 for ; Fri, 26 Sep 2025 09:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758905504; x=1759510304; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i0T8zq8INccPbQUCoQRij5qCg9hoKwVCcpVN7/O7FiI=; b=Qs37YasNQFelATTu8t3Yiixsfs4zZTQezOXA6RP5PWva6TTfwB49raj9KWjiTELXXe Nf5UCz5Zhy9yjOuTCV3w4YJLcaXzNahuu6VhV5kVMc+mY3BUnr3p2At5qKp/Bd+OkGYo 35ndSzBX59TezCkFpByV13sjWER6ksqlbNL4ruFvfP5EShHUbAptQTRiLvm6Y4/liJ/g uObWnlAqAYN6ytlBrKdT9MAbxVy5hHEbAvZZ7A3av74KbIKV+EjlisRFu912mls+9PFp Vhhp/lA3nyM8zlCwBrpre5zDZSg4u264dzhMOPfZG2cLGaj6jJSwBL+WYhLzvK7n+6C+ 0f4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758905504; x=1759510304; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i0T8zq8INccPbQUCoQRij5qCg9hoKwVCcpVN7/O7FiI=; b=jkDsWmZY5xiytG4pSulkDHOF7S2irKy44lm6WZ74B9Np/tur9xZHH+45Rnd4mLO1vi GGeYs/JJA+4pBwdM2vJzJXA8reqXXmqGFQQ3D+INxfaBDNAUuwLZ9Ax4Yr9bCu7m3Hc1 +DMJCnckMoa7LDQ2aft4InIqmKg90qjfQ6/WrSDiGzaxnmaxtwvnxuABVl5KJx6lF58U 9pUUGHISSZNjyc2+q/0tyezU0JrMjTMsZ1JP1mAh4meyiLuaPKiEAjSWgPPyWcWLgRDR /KR0SoX8g468oMpXSkw8NdoaAJ1Vk/T7DnjBWw9nmJDZQMGQBr29LqolU0EPJk1uF2QF icBA== X-Gm-Message-State: AOJu0YymerHrRrhCyq2ZrbYMYRRaXPiq48HZ8877W+1otllvyruDhk/7 pV2rNSTlLqxQB/9YqTf1JEw7dPlZIOFJk8u8xvWlTl4cHQTI9fpYmOpVoPYrVbJS86VBZ8G4Fy2 rCI8KfTm45+LRHBocDDUnIS5Jvx4X5C9oWQ== X-Gm-Gg: ASbGncvdzZThAuyKsRMMpaIamuElpTjLnGtSEi3SIXgMW4oQRbulY5L6Dy6p5RVSV1U FVDz12t9os98VtGpNMzAKgWJgY8IQYLvJubja8IyLna37zCjzwsTWwwA4e2WeT/Anr99l8IMroD i9Kew0vqEzLyAbv/xiiFPiszI89YaRUM9HqUMcQromnaAciGop2sBYZvmyaJ+4LIF3LP8i8iYME WmUjfyxElWhfi/fvamtC1nsdnV40yJGcklcQFE1FOJ2cUxiO3Ez2D2RS/6P X-Google-Smtp-Source: AGHT+IHUAACQ0ccQ9mxOd6cgn56kHnXPXoggvPfSaEeu4FEU3ougv9n9CxQQ1miJxf40godlS0Fdqpbw7QxPEf9RJ/8= X-Received: by 2002:a17:906:d550:b0:b04:725c:bcb with SMTP id a640c23a62f3a-b34b86a1934mr853455266b.23.1758905503566; Fri, 26 Sep 2025 09:51:43 -0700 (PDT) MIME-Version: 1.0 References: <20250923233332.2748851-1-lsandova@redhat.com> In-Reply-To: From: Andrew Hamilton Date: Fri, 26 Sep 2025 11:51:32 -0500 X-Gm-Features: AS18NWA5a0wTO7mrNyH4TqpBOSVslC9WL89uGLyYmpQDMCcubjA6Sz5Hn6l3XcQ Message-ID: Subject: Re: [PATCH v2 1/2] Make grub_error() more verbose To: The development of GNU GRUB Cc: "Vladimir 'phcoder' Serbinenko" , Leo Sandoval Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=adhamilt@gmail.com; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The development of GNU GRUB Content-Type: multipart/mixed; boundary="===============5041689047473084305==" Errors-To: grub-devel-bounces+grub-devel=archiver.kernel.org@gnu.org Sender: grub-devel-bounces+grub-devel=archiver.kernel.org@gnu.org --===============5041689047473084305== Content-Type: multipart/alternative; boundary="000000000000bbe330063fb71931" --000000000000bbe330063fb71931 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How large is the i386 pc user base, do you think including a conditional compile to only add for uefi 64-bit covers most cases? Just a thought. Thanks, Andrew On Fri, Sep 26, 2025 at 11:16=E2=80=AFAM Leo Sandoval via Grub-devel < grub-devel@gnu.org> wrote: > > > On Fri, Sep 26, 2025 at 9:58=E2=80=AFAM Vladimir 'phcoder' Serbinenko < > phcoder@gmail.com> wrote: > >> >> >> Le jeu. 25 sept. 2025, 21:04, Leo Sandoval a >> =C3=A9crit : >> >>> >>> >>> On Wed, Sep 24, 2025 at 1:55=E2=80=AFPM Vladimir 'phcoder' Serbinenko < >>> phcoder@gmail.com> wrote: >>> >>>> What is the influence on core.img size on i386-pc? Are we still within >>>> our promises for supporting 31K gaps with simple config? >>>> >>> >>> running this in both grub versions >>> >>> $ grub2-mkimage -O i386-pc -p /tmp -o core.img biosdisk part_msdos ext2 >>> >>> core.img file increases from 34538 to 35132 bytes, so the increase is >>> about 0.6K. >>> >> >> 0.6K out of 31K is a lot. Is there a way to decrease this overhead? >> > > I forgot to indicate that this increase includes this patch and the other > in the series, which includes the function name also. In general, this 0.= 6K > increase includes the file:function:line_number on the logs. > > No idea how to decrease it. Any suggestion to try? > > >> >> >>>>> extern grub_err_t EXPORT_VAR(grub_errno); >>>>> extern char EXPORT_VAR(grub_errmsg)[GRUB_MAX_ERRMSG]; >>>>> >>>>> -grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *fmt, >>>>> ...) >>>>> - __attribute__ ((format (GNU_PRINTF, 2, 3))); >>>>> +grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *file, >>>>> const int line, const char *fmt, ...) >>>>> + __attribute__ ((format (GNU_PRINTF, 4, 5))); >>>>> + >>>>> +#define grub_error(n, fmt, ...) grub_error (n, __FILE__, __LINE__, >>>>> fmt, ##__VA_ARGS__) >>>>> + >>>>> + >>>>> void EXPORT_FUNC(grub_fatal) (const char *fmt, ...) __attribute__ >>>>> ((noreturn)); >>>>> void EXPORT_FUNC(grub_error_push) (void); >>>>> int EXPORT_FUNC(grub_error_pop) (void); >>>>> -- >>>>> 2.50.1 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Grub-devel mailing list >>>>> Grub-devel@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/grub-devel >>>>> >>>> _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > --000000000000bbe330063fb71931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How large is the i386 pc user base, do you think includin= g a conditional compile to only add for uefi 64-bit covers most cases?

Just a thought.

Thanks,
Andre= w

On Fri, Sep 26, 2025 at 11:16=E2=80=AFAM Leo = Sandoval via Grub-devel <grub-deve= l@gnu.org> wrote:


On Fri, Sep 26, 2025 at 9:58=E2=80=AFAM Vladimir 'phcod= er' Serbinenko <phcoder@gmail.com> wrote:


Le jeu. 25 sept. 2025, 21:04, Leo Sandoval &l= t;lsandova@redhat.= com> a =C3=A9crit=C2=A0:
=


On Wed, Sep 24, 2025 at 1:55=E2=80=AFPM Vladimir '= phcoder' Serbinenko <phcoder@gmail.com> wrote:
What is the influence on core.img size on= i386-pc? Are we still within our promises for supporting 31K gaps with sim= ple config?
=C2=A0
running this in b= oth grub versions

$ grub2-mkimage -O i386-pc -p /t= mp -o core.img biosdisk part_msdos ext2

core.img f= ile increases from=C2=A0 34538 to=C2=A035132 bytes, so the increase is abou= t 0.6K.

0.6K out of 31K is a lot. Is there a way to decrease t= his overhead?

I forgot to indic= ate that this increase includes this patch and the other in the series, whi= ch includes the function name also. In general, this 0.6K increase includes= the file:function:line_number on the logs.

No ide= a how to decrease it. Any suggestion to try?=C2=A0
=C2=A0


=C2=A0extern grub_err_t EXPORT_VAR(grub_errno);
=C2=A0extern char EXPORT_VAR(grub_errmsg)[GRUB_MAX_ERRMSG];

-grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *fmt, ...) -=C2=A0 =C2=A0 __attribute__ ((format (GNU_PRINTF, 2, 3)));
+grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *file, const = int line, const char *fmt, ...)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0__attribute__ ((format (GNU_PRINTF, 4, 5))); +
+#define grub_error(n, fmt, ...) grub_error (n, __FILE__, __LINE__, fmt, ##= __VA_ARGS__)
+
+
=C2=A0void EXPORT_FUNC(grub_fatal) (const char *fmt, ...) __attribute__ ((n= oreturn));
=C2=A0void EXPORT_FUNC(grub_error_push) (void);
=C2=A0int EXPORT_FUNC(grub_error_pop) (void);
--
2.50.1


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman= /listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org<= /a>
https://lists.gnu.org/mailman/listinfo/grub-devel
--000000000000bbe330063fb71931-- --===============5041689047473084305== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KR3J1Yi1kZXZl bCBtYWlsaW5nIGxpc3QKR3J1Yi1kZXZlbEBnbnUub3JnCmh0dHBzOi8vbGlzdHMuZ251Lm9yZy9t YWlsbWFuL2xpc3RpbmZvL2dydWItZGV2ZWwK --===============5041689047473084305==--