On Wed, 13 May 2020 18:24:28 +0200
Daniel Kiper <dki...@net-space.pl> wrote:

> On Fri, May 08, 2020 at 06:50:48AM +0200, Hans Ulrich Niedermann
> wrote:
> > The example kernel has assembly language boot code for both
> > i386 and mips, but the mips assembly code used to be built
> > unconditionally, even if the build is using non-mips build
> > tools such as for x86_64 or i386.
> >
> > This makes the example kernel build at least for i386, both
> > on i386 and on x86_64 hosts.
> >
> >   * renames the i386 boot code from boot.S to boot_i386.S
> >     to go along with the mips boot code in boot_mips.S
> >
> >   * adds AC_CANONICAL_HOST to select the proper boot code:
> >
> >       * i386 if building on x86_64 (adds -m32) or on i[3456]86
> >       * mips if building for mips*
> >       * do not build the kernel if building for another system
> >
> >   * adds m4 quoting and uses AS_HELP_STRING use in configure.ac
> >
> >   * fixes the name of the constants used in boot_i386.S
> >     to use the actual constant names from multiboot2.h
> >
> >   * documents both boot_i386.S and boot_mips.S in the
> >     multiboot.texi page  
> 
> May I ask you to split this patch into logical parts?

Being a little slow on the uptake, I only just figured out why I ended
up with that big of a patch.

When given a building and working source tree, I usually make my commits
such that they are small, self-contained and keep the source tree in a
building and working state.

That is why I usually add changes until it finally builds/works.

However, that is a useless argument here, as the state of the source
tree *before* my change is non-building maybe-working, so if the source
tree does not build *after* my small, self-contained change, my change
has not made it worse and can thusly still be considered good.

Changing my normal modus operandi accordingly; considering failing
builds as normal for now.

Expect a good dozen patches in a day or two.

Uli

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to