[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1538628062.18776.5.camel@HansenPartnership.com>
Date: Wed, 03 Oct 2018 21:41:02 -0700
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Leonardo Bras <leobras.c@...il.com>
Cc: lkcamp@...ts.libreplanetbr.org,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Finn Thain <fthain@...egraphics.com.au>,
Robert Richter <rric@...nel.org>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Helge Deller <deller@....de>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-m68k@...ts.linux-m68k.org, oprofile-list@...ts.sf.net,
linux-parisc@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if
CONFIG_PARISC is disabled
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote:
> On Fri, Sep 28, 2018 at 4:15 AM James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> >
> > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote:
> > > Avoids building driver if 'make drivers/parisc/' is called and
> > > CONFIG_PARISC is disabled.
> >
> > Is that really a problem? The drivers/Makefile has this:
> >
> > obj-$(CONFIG_PARISC) += parisc/
> > And you just overrode that by forcing the build. It's not even
> > clear we should refuse the build in that case; how would we know
> > you don't have a legitimate reason for the override?
> >
>
> Sorry I did not explained my reasons earlier. I sent everybody
> involved an e-mail explaining the full reason of this change.
> (For reference it's here: https://lkml.org/lkml/2018/10/3/707)
Well it's not really that persuasive. Most people simply let the build
run to completion, but if you have a problem with a job control 3h
timelimit, then create a job that kills itself at 2:59 and then
resubmits itself. That will produce a complete build in 3h chunks
without any need to call sub Makefiles.
All of our Makefiles are coded assuming the upper level can prevent
descent into the lower ones. You're proposing to change that
assumption, requiring a fairly large patch set, which doesn't really
seem to provide a huge benefit.
James
> > Signed-off-by: Leonardo Brás <leobras.c@...il.com>
> > > ---
> > > drivers/parisc/Makefile | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile
> > > index 3cd5e6cb8478..80049d763aa0 100644
> > > --- a/drivers/parisc/Makefile
> > > +++ b/drivers/parisc/Makefile
> > > @@ -24,5 +24,5 @@ obj-$(CONFIG_EISA) += eisa.o
> > > eisa_enumerator.o eisa_eeprom.o
> > > obj-$(CONFIG_SUPERIO) += superio.o
> > > obj-$(CONFIG_CHASSIS_LCD_LED) += led.o
> > > obj-$(CONFIG_PDC_STABLE) += pdc_stable.o
> > > -obj-y += power.o
> > > +obj-$(CONFIG_PARISC) += power.o
> >
> > If we conclude the use case is legitimate, that's not enough: the
> > two
> > inner symbols are PARISC only but CONFIG_EISA isn't.
>
> You are right.
> It worked for my needs because I am only building the drivers, and
> not linking them. But i believe doing something like I did in
> zorro/Makefile would fix this all. (For reference,
> https://lkml.org/lkml/2018/9/28/150 )
>
> If you agree, I will send the next patchset with this change.
>
> Thanks for your help!
>
> Leonardo Bras
>
Powered by blists - more mailing lists