From: Daniel Kiper <dkiper@net-space.pl>
To: Michael Chang via Grub-devel <grub-devel@gnu.org>
Cc: Michael Chang <mchang@suse.com>,
Colin Watson <cjwatson@debian.org>,
Glenn Washburn <development@efficientek.com>,
Marco A Benatto <mbenatto@redhat.com>,
Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH v2] i386-pc: build verifiers API as module
Date: Wed, 14 Apr 2021 15:22:35 +0200 [thread overview]
Message-ID: <20210414132235.pr3jl32qb3op2e57@tomti.i.net-space.pl> (raw)
In-Reply-To: <20210413041302.GA24779@mercury>
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?
Daniel
next prev parent reply other threads:[~2021-04-14 13:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 11:30 [PATCH v2] i386-pc: build verifiers API as module Michael Chang
2021-03-22 15:20 ` Daniel Kiper
2021-03-22 16:16 ` Colin Watson
2021-03-22 20:09 ` Colin Watson
2021-03-22 20:19 ` Glenn Washburn
2021-03-22 20:45 ` Colin Watson
2021-03-23 16:33 ` Daniel Kiper
2021-03-23 17:45 ` Lennart Sorensen
2021-03-24 4:44 ` Michael Chang
2021-03-26 17:01 ` Daniel Kiper
2021-04-12 13:15 ` Daniel Kiper
2021-04-13 4:13 ` Michael Chang
2021-04-14 13:22 ` Daniel Kiper [this message]
2021-04-16 21:23 ` Colin Watson
2021-04-20 3:49 ` Michael Chang
2021-04-28 13:45 ` Daniel Kiper
2021-03-22 21:43 ` James Bottomley
2021-03-23 4:16 ` Michael Chang
2021-03-23 11:37 ` Javier Martinez Canillas
2021-03-23 13:27 ` Colin Watson
2021-03-23 14:26 ` Javier Martinez Canillas
2021-03-23 17:26 ` Daniel Kiper
2021-03-23 16:48 ` Daniel Kiper
2021-03-24 3:50 ` Michael Chang
2021-03-26 17:22 ` Daniel Kiper
2021-08-22 19:50 Michael Schierl
2021-08-22 20:23 ` Didier Spaier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210414132235.pr3jl32qb3op2e57@tomti.i.net-space.pl \
--to=dkiper@net-space.pl \
--cc=cjwatson@debian.org \
--cc=development@efficientek.com \
--cc=grub-devel@gnu.org \
--cc=javierm@redhat.com \
--cc=mbenatto@redhat.com \
--cc=mchang@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.