Re: [PATCH 5/7] x86: remove always-defined CONFIG_AS_SSSE3

[Jason A. Donenfeld]

On Mon, Mar 23, 2020 at 2:45 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Tue, Mar 24, 2020 at 3:06 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> >
> > On Sun, Mar 22, 2020 at 8:10 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> > > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > > index bf1b4765c8f6..77457ea5a239 100644
> > > --- a/lib/raid6/algos.c
> > > +++ b/lib/raid6/algos.c
> > > @@ -103,9 +103,7 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
> > >  #ifdef CONFIG_AS_AVX2
> > >         &raid6_recov_avx2,
> > >  #endif
> > > -#ifdef CONFIG_AS_SSSE3
> > >         &raid6_recov_ssse3,
> > > -#endif
> > >  #ifdef CONFIG_S390
> > >         &raid6_recov_s390xc,
> > >  #endif
> >
> > algos.c is compiled on all platforms, so you'll need to ifdef that x86
> > section where SSSE3 is no longer guarding it. The pattern in the rest
> > of the file, if you want to follow it, is "#if defined(__x86_64__) &&
> > !defined(__arch_um__)". That seems ugly and like there are better
> > ways, but in the interest of uniformity and a lack of desire to
> > rewrite all the raid6 code, I went with that in this cleanup:
> >
> > https://git.zx2c4.com/linux-dev/commit/?h=jd/kconfig-assembler-support&id=512a00ddebbe5294a88487dcf1dc845cf56703d9
>
>
> Thanks for the pointer,
> but I think guarding with CONFIG_X86 makes more sense.
>
> raid6_recov_ssse3 is defined in lib/raid6/recov_ssse3.c,
> which is guarded by like this:
>
> raid6_pq-$(CONFIG_X86) += recov_ssse3.o recov_avx2.o mmx.o sse1.o
> sse2.o avx2.o avx512.o recov_avx512.o
>
>
> Indeed,
>
>  #if defined(__x86_64__) && !defined(__arch_um__)
>
> is ugly.
>
>
> I wonder why the code was written like that.
>
> I rather want to check a single CONFIG option.
> Please see the attached patch.

Seems better indeed. Looks like you've cleaned up multiple cases.

Now if you could only tell me what is wrong with my series... "Your
series does not work correctly. I will comment why later." I've been
at the edge of my seat, Fermat's last theorem style. :)

By the way, it looks like 5.7 will be raising the minimum binutils to
2.23: https://lore.kernel.org/lkml/20200316160259.GN26126@xxxxxxx/ In
light of this, I'll place another patch on top of my branch handling
that transition.

Jason