All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Richter <rric@kernel.org>
To: "Leonardo Brás" <leobras.c@gmail.com>
Cc: lkcamp@lists.libreplanetbr.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Finn Thain <fthain@telegraphics.com.au>,
	"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@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 0/7]  Remove errors building drivers/DRIVERNAME
Date: Mon, 1 Oct 2018 09:56:07 +0200	[thread overview]
Message-ID: <20181001075607.GA3776@rric.localdomain> (raw)
In-Reply-To: <20180928020816.11251-1-leobras.c@gmail.com>

On 27.09.18 23:08:09, Leonardo Brás wrote:
> This Patchset changes some driver's Makefile to allow them building
> using the command 'make drivers/DRIVERNAME', if compatible.
> 
> The changed drivers would return error if the above command was run
> on them, after an x86 allyesconfig.

I don't see what you are trying to achieve here. Why shouldn't the
command fail if it is not the intended way to call it? There are a
couple of use cases where drivers/ is used to share common code over
different archs and it is not always the intention to build them in
drivers/ directly.

> 
> The main reason of this patchset is to allow building lists of
> drivers looking for warnings and errors to be fixed.

If a list is the intention here, aren't there other ways to create it
other than using drivers/*?

-Robert

> 
> I see this change as a new feature, not a bugfix. I understand
> the default bahavior may be building with a simple 'make', but I
> believe adding this new possibility will not be harmful.
> 
> My main objective is to allow developers with low processing power
> to do changes in the kernel and look bugs using free services like
> GiltabCI, before submitting to community.
> 
> If there is any interest helping/using this, I have a prototype in:
> https://gitlab.com/LeoBras/linux-next

  parent reply	other threads:[~2018-10-01  7:56 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
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 ` Robert Richter [this message]
2018-10-03 15:46   ` [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME 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:45 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=20181001075607.GA3776@rric.localdomain \
    --to=rric@kernel.org \
    --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=leobras.c@gmail.com \
    --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=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.