All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Ben Dooks <ben-linux@fluff.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Linux Samsung SoC <linux-samsung-soc@vger.kernel.org>,
	jassi brar <jassisinghbrar@gmail.com>
Subject: Re: Problems with device compilation by subsystem config
Date: Thu, 28 Jan 2010 09:32:33 +0000	[thread overview]
Message-ID: <20100128093233.GA7339@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100128070518.GS10014@trinity.fluff.org>

On Thu, Jan 28, 2010 at 07:05:18AM +0000, Ben Dooks wrote:

> My first response is that this forces the user to rebuild the kernel
> every time they decide to change the subsytems included, which if just
> building things as modules isn't nice. However this wasn't a strong enough
> objection at the time to reject the patches.

> People might say that building everything is a waste of kernel space, but
> we cluttering mach-xxx.c with #ifdefs is also not pleasant, and if we have
> as currently for many of the other devices CONFIG to build the devices
> selected by the machine then we are reasonably efficient.

I tend to agree that the space savings being pointless on a system like
S3C64xx - on S3C24xx RAM is likely to be much more precious but if
the processor is something like the S3C64xx the resource used by the
device definitions is unlikely to be meaningful.  I only included the
conditional build for the audio device because the existing code for I2C,
SDHCI and so on was doing the same.

> To fix thsi I propose changing the SPI and Audio support to have their
> own 'config S3C_DEV_xxx' entries which are selected by the boards that
> use them (this removes the need for #ifdef in the board file) and these
> entries should not be dependant on the subsytem defines.

To be honest I'd be inclined to just unconditionally include them.  I
suspect if they're genuinely unused the linker ought to be able to
discard them anyway.

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: Problems with device compilation by subsystem config
Date: Thu, 28 Jan 2010 09:32:33 +0000	[thread overview]
Message-ID: <20100128093233.GA7339@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100128070518.GS10014@trinity.fluff.org>

On Thu, Jan 28, 2010 at 07:05:18AM +0000, Ben Dooks wrote:

> My first response is that this forces the user to rebuild the kernel
> every time they decide to change the subsytems included, which if just
> building things as modules isn't nice. However this wasn't a strong enough
> objection at the time to reject the patches.

> People might say that building everything is a waste of kernel space, but
> we cluttering mach-xxx.c with #ifdefs is also not pleasant, and if we have
> as currently for many of the other devices CONFIG to build the devices
> selected by the machine then we are reasonably efficient.

I tend to agree that the space savings being pointless on a system like
S3C64xx - on S3C24xx RAM is likely to be much more precious but if
the processor is something like the S3C64xx the resource used by the
device definitions is unlikely to be meaningful.  I only included the
conditional build for the audio device because the existing code for I2C,
SDHCI and so on was doing the same.

> To fix thsi I propose changing the SPI and Audio support to have their
> own 'config S3C_DEV_xxx' entries which are selected by the boards that
> use them (this removes the need for #ifdef in the board file) and these
> entries should not be dependant on the subsytem defines.

To be honest I'd be inclined to just unconditionally include them.  I
suspect if they're genuinely unused the linker ought to be able to
discard them anyway.

  parent reply	other threads:[~2010-01-28  9:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-28  7:05 Problems with device compilation by subsystem config Ben Dooks
2010-01-28  7:05 ` Ben Dooks
2010-01-28  7:27 ` jassi brar
2010-01-28  7:27   ` jassi brar
2010-01-28  9:32 ` Mark Brown [this message]
2010-01-28  9:32   ` Mark Brown

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=20100128093233.GA7339@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=ben-linux@fluff.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    /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.