Prev: vhost-net fixes
Next: Drivers: net: 8139cp: Improved conformance to the Linux coding style guidelines.
From: Arnd Bergmann on 16 Jul 2010 16:10
On Friday 16 July 2010 19:57:55 Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> <catalin.marinas(a)arm.com> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it actually workable for
> me (without my ugly post-processing step). I was very happy to hear
> that it is in linux-next.
>
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.

Are there a lot of symbols for which this is needed? If there is only
a handful, you could work around this by selectively adding

config FOO
bool "foo"
default !FOO_DISABLE

config FOO_DISABLE
def_bool "n"


Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 16 Jul 2010 16:20
On Friday 16 July 2010 20:46:17 Linus Torvalds wrote:
> Maybe a full "solver" is unnecessary, for example, but just a simple
> "automatically enable the direct dependencies and scream when it's not
> simple any more" would take care of 99% of the common cases, and then
> warn when it needs some manual help.

I think the recursion should also be limited to cases where the
dependency is a valid selectable option, i.e. not for

# this architecture does not support MMIO
config HAS_IOMEM
def_bool 'n'

config PCI
bool "PCI Device drivers"
depends on HAS_IOMEM

config FOO
tristate "Some device driver"
depends on PCI

In this case, it would be straightforward for the solver to enable PCI
for when something selects CONFIG_FOO, but it should print a warning
if this is attempted while HAS_IOMEM is unconditionally disabled,
since that puts it into the "not simple" category.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 16 Jul 2010 19:50
Daniel Walker wrote:
> > But all the rest is arbitrary and could be part of common shared
> > profiles or the like in defconfig format.
>
> I'm sure most people will want to have a config isolated to their
> specific device. That to me seems reasonable because everyone wants the
> smallest possible kernel they can get for their given device.

Indeed, but people who want the smallest possible kernel for their
specific device _in a particular use context_ tend to want:

- To disable support for parts of the device they aren't using.
For example, an SoC with integrated ethernet that isn't actually
wired up on their board, or where they're using an external ethernet
chip instead for some reason.

- To choose what's modular and what isn't, even for integrated
parts. For example to control the bootup sequence, they might
want to delay integrated USB and IDE initialisation, which is done by
making those modular and loading them after bringing up a splash
screen earlier in the boot scripts.

So there is still a need to be able to override the drivers and
settings, but it's still incredibly useful to have defaults which
describe the SoC or board accurately.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: vhost-net fixes
Next: Drivers: net: 8139cp: Improved conformance to the Linux coding style guidelines.