Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Thu, 6 Feb 2020 09:18:48 +0100 | Subject | Re: [PATCH 1/2] staging: octeon: delete driver |
| |
Hi Günter,
On Wed, Feb 5, 2020 at 2:52 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 2/5/20 1:03 AM, Geert Uytterhoeven wrote: > > On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck <linux@roeck-us.net> wrote: > >> On 2/4/20 7:34 PM, Dan Carpenter wrote: > >>> On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matthew Wilcox wrote: > >>>> On Tue, Feb 04, 2020 at 08:06:14PM +0000, Chris Packham wrote: > >>>>> On Tue, 2020-02-04 at 07:09 +0000, gregkh@linuxfoundation.org wrote: > >>>>>> On Tue, Feb 04, 2020 at 04:02:15AM +0000, Chris Packham wrote: > >>>>> On Tue, 2020-02-04 at 10:21 +0300, Dan Carpenter wrote: > >>>>>> My advice is to delete all the COMPILE_TEST code. That stuff was a > >>>>>> constant source of confusion and headaches. > >>>>> > >>>>> I was also going to suggest this. Since the COMPILE_TEST has been a > >>>>> source of trouble I was going to propose dropping the || COMPILE_TEST > >>>>> from the Kconfig for the octeon drivers. > >>>> > >>>> Not having it also causes problems. I didn't originally add it for > >>>> shits and giggles. > >>> > >>> I wonder if the kbuild bot does enough cross compile build testing these > >>> days to detect compile problems. It might have improved to the point > >>> where COMPILE_TEST isn't required. > > > > It depends... > > > >> Not really. Looking at the build failures in the mainline kernel right now: > >> > >> Failed builds: > >> alpha:allmodconfig > >> arm:allmodconfig > >> i386:allyesconfig > >> i386:allmodconfig > >> m68k:allmodconfig > >> microblaze:mmu_defconfig > >> mips:allmodconfig > >> parisc:allmodconfig > >> powerpc:allmodconfig > >> s390:allmodconfig > >> sparc64:allmodconfig > > > > I did receive a report from noreply@ellerman.id.au for the m68k build > > failure. But that was sent to me only, not to the offender, and I do my > > own builds anyway. > > > > More interesting, that report happened after the offending commit landed > > upstream, while it had been in next for 4 weeks. > > m68k in -next builds fine for me, and did for a while. I have not seen a build > failure there. There must be a context commit causing this failure, or what > is (or was) in -next differs from what is in mainline.
Indeed. The offending symbol depended on another symbol, which never made it to next before it hit mainline, thus hiding the issue.
> >> Many of those don't even _have_ specific configurations causing the build failures. > > > > Exactly. These are the "easy" ones, as the all*config builds enable as > > much infrastructure as possible. It's much harder if some common > > dependency is not fulfilled in some specific config. > > Yes, that is correct. But that doesn't mean that it would be a good idea > to retire COMPILE_TEST.
I agree.
Retiring COMPILE_TEST could have a positive side-effect, though: it would reduce the compile time for all*config, which might give the overloaded build bots spare cycles to cover other configs.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
| |