All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Bras <leobras.c@gmail.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: lkcamp@lists.libreplanetbr.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Finn Thain <fthain@telegraphics.com.au>,
	Robert Richter <rric@kernel.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-m68k@lists.linux-m68k.org, oprofile-list@lists.sf.net,
	linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled
Date: Thu, 4 Oct 2018 23:16:24 -0300	[thread overview]
Message-ID: <CADvQ+rG0WQjFTU=A4tAACvqFevw51DX_-yq2-9j78T8pSrjcXQ@mail.gmail.com> (raw)
In-Reply-To: <1538628062.18776.5.camel@HansenPartnership.com>

> 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.
>

Humm, I probably should have explained better how GitlabCI works.
It works creating a docker container that have a limited lifespan of 3h max.
After that the time is over, this container ceases to exist, leaving no build
objects, only the console log. So there is no way of 'resuming' the building
from where it stopped. I used the 'job' term because it's how they call it,
and I understand it's easily confused with bash jobs.

> 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

I understand your viewpoint.
But what I propose is not to change that assumption, but instead give some
Makefiles the aditional ability to be called directly and still not build stuff
if they were not enabled in .config.

But, why these chosen Makefiles, and not all of them?
Granularity.
What I am trying to achieve with this patchset is the ability of building
smaller sets of drivers without accidentally building what is not enabled
on .config.
And, in my viewpoint, building a single drivers/DRIVERNAME is small enough to
be fast in most situations.

This change is not supposed to bother the usual way of building the kernel, and
it is not even supposed to add overhead to kernel compilation. And it would,
at least, solve my problem with the 3h limit, and enable the tool
I am building on GiltabCI to help other developers.

Thanks for reading,

Leonardo Bras

  reply	other threads:[~2018-10-05  2:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28  2:08 [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME Leonardo Brás
2018-09-28  2:08 ` [PATCH v3 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled Leonardo Brás
2018-09-28  2:08 ` [PATCH v3 2/7] drivers: nubus: Avoids building driver if CONFIG_NUBUS " Leonardo Brás
2018-09-28  2:08 ` [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC " Leonardo Brás
2018-09-28  7:15   ` James Bottomley
2018-10-04  0:31     ` Leonardo Bras
2018-10-04  0:31       ` Leonardo Bras
2018-10-04  4:41       ` James Bottomley
2018-10-05  2:16         ` Leonardo Bras [this message]
2018-10-05  4:10           ` Finn Thain
2018-10-06  4:28           ` Michael Schmitz
2018-10-10  1:01             ` Leonardo Bras
2018-09-28  2:08 ` [PATCH v3 4/7] drivers: zorro: Avoids building proc.o if CONFIG_ZORRO " Leonardo Brás
2018-09-28  2:08 ` [PATCH v3 5/7] drivers: s390: Avoids building drivers if ARCH is not s390 Leonardo Brás
2018-10-01 12:46   ` Heiko Carstens
2018-10-04  1:00     ` Leonardo Bras
2018-10-04  1:00       ` Leonardo Bras
2018-09-28  2:08 ` [PATCH v3 6/7] drivers: oprofile: Avoids building driver from direct make command Leonardo Brás
2018-09-28  2:08 ` [PATCH v3 7/7] drivers: hwtracing: Adds Makefile to enable building from directory Leonardo Brás
2018-10-01  7:56 ` [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME Robert Richter
2018-10-03 15:46   ` Leonardo Bras
2018-10-03 15:46     ` Leonardo Bras
2018-10-03 23:27     ` Finn Thain
2018-10-04  1:37       ` Leonardo Bras
2018-10-04  2:00         ` Finn Thain
2018-10-10  1:04           ` Leonardo Bras
  -- strict thread matches above, loose matches on Subject: below --
2018-09-28  1:48 [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled Leonardo Brás

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='CADvQ+rG0WQjFTU=A4tAACvqFevw51DX_-yq2-9j78T8pSrjcXQ@mail.gmail.com' \
    --to=leobras.c@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=deller@gmx.de \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jejb@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lkcamp@lists.libreplanetbr.org \
    --cc=oprofile-list@lists.sf.net \
    --cc=rric@kernel.org \
    --cc=schwidefsky@de.ibm.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.