Prev: Kconfig: Enable Kconfig fragments to be used for defconfig
Next: AT91 NOMMU fails to compile 2.6.35-rc5
From: Daniel Walker on 13 Jul 2010 19:20
On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:

> - I haven't figured out a way for the fragment to force an option to
> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> This may require changing the syntax.
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.

The solver would fix the whole issues with the defconfigs , we wouldn't
need this Kconfig change .. From my perspective we shouldn't be fooling
around with anything but the solver approach ..

It just doesn't feel like Kconfig was meant to do this, it feel like
somewhat of an abuse ..

Daniel

--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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: Nicolas Pitre on 13 Jul 2010 20:10
On Tue, 13 Jul 2010, Daniel Walker wrote:
> On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> > On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker(a)codeaurora.org> wrote:
> > > It just doesn't feel like Kconfig was meant to do this, it feel like
> > > somewhat of an abuse ..
> >
> > Why? It uses the Kconfig language itself to specify additional
> > constraints on the final configuration. Seems to be the essence of
> > elegance to me. :-)
>
> To my mind the only problem with the current defconfig formatting is the
> size of the files. If those files are 5-10 lines instead of 2000 lines,
> then I think the readability problem isn't really an issue any more..

That's one issue indeed.

But there is another issue that is somewhat related, which is to be able
to categorize config options.

Currently the defconfig files carry information about the proper driver
to enable in order to support devices soldered on the board and
therefore which are not "optional". That might be a particular RTC
chip, or a particular ethernet block integrated into a SOC, etc. Of
course we want to preserve the ability to disable support for those
things, but by default people want to have all the right drivers
selected for all the built-in hardware when selecting a target
machine/board without having to dig into a datasheet for that target.

The defconfig files also carry config options that are totally
arbitrary. What type of filesystem, what kind of network protocol, what
USB device drivers (not host controller driver), what amount of
debugging options, all those are unrelated to the actual hardware and
may vary from one user to another.

Furthermore, in order to reduce the number of defconfig files, we tried
to combine as many targets into a single kernel image. That increases
build test coverage with fewer builds which is good, but then the info
about specific drivers required for a specific target but not for
another target in the same defconfig is now lost. It is therefore quite
hard to produce a highly optimized configuration for a single target
without doing some digging again.

So it is really in the Kconfig file that all those hardware specific
options can be expressed in a clear and readable way. When BOARD_XYZ is
selected and STD_CONFIG is selected, then automatically select RTC_FOO,
select ETH_BAR, select LED_BAZ, etc. Of course we would want required
dependencies to be automatically selected as well.

But all the rest is arbitrary and could be part of common shared
profiles or the like in defconfig format.


Nicolas
--
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: Daniel Walker on 14 Jul 2010 12:30
On Tue, 2010-07-13 at 20:07 -0400, Nicolas Pitre wrote:

> That's one issue indeed.
>
> But there is another issue that is somewhat related, which is to be able
> to categorize config options.
>
> Currently the defconfig files carry information about the proper driver
> to enable in order to support devices soldered on the board and
> therefore which are not "optional". That might be a particular RTC
> chip, or a particular ethernet block integrated into a SOC, etc. Of
> course we want to preserve the ability to disable support for those
> things, but by default people want to have all the right drivers
> selected for all the built-in hardware when selecting a target
> machine/board without having to dig into a datasheet for that target.
>
> The defconfig files also carry config options that are totally
> arbitrary. What type of filesystem, what kind of network protocol, what
> USB device drivers (not host controller driver), what amount of
> debugging options, all those are unrelated to the actual hardware and
> may vary from one user to another.

Right.

> Furthermore, in order to reduce the number of defconfig files, we tried
> to combine as many targets into a single kernel image. That increases
> build test coverage with fewer builds which is good, but then the info
> about specific drivers required for a specific target but not for
> another target in the same defconfig is now lost. It is therefore quite
> hard to produce a highly optimized configuration for a single target
> without doing some digging again.
>
> So it is really in the Kconfig file that all those hardware specific
> options can be expressed in a clear and readable way. When BOARD_XYZ is
> selected and STD_CONFIG is selected, then automatically select RTC_FOO,
> select ETH_BAR, select LED_BAZ, etc. Of course we would want required
> dependencies to be automatically selected as well.

I see..

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

Then there would be a smaller group who wants to create multi-device
images. I don't see this being the average users tho, or kernel hackers.

To me there is little difference between doing,

CONFIG_ARCH_MSM=y

or

select ARCH_MSM

they are basically doing the same thing. So doing anything in Kconfig is
a lateral move .. Converting over to Kconfig in this case doesn't makes
sense to me.

Could we do something more like adding an "#include" option into the
defconfigs .. Then you could create defconfigs that hold multiple
devices without a massive rework to what we currently have.

Daniel


--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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: Catalin Marinas on 16 Jul 2010 12:10
On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.

It's not a solver but I'm pushing a patch to warn on selecting symbols
with unmet dependencies so that you can select further symbols (manual
solving). The patch is in linux-next but you also can grab it from:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f

--
Catalin

--
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: Nicolas Pitre on 16 Jul 2010 14:20
On Fri, 16 Jul 2010, 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:
> >> - It still doesn't resolve dependencies. �A solver would help with this.
> >> � For the time being I work around the problem by running the generated
> >> � config through 'oldconfig' and looking for differences. �If the files
> >> � differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> � then the <board>_defconfig target returns a failure. �(but leaves the
> >> � new .config intact so the user can resolve it with menuconfig). �This
> >> � way at least the user is told when a Kconfig fragment is invalid.
> >
> > It's not a solver but I'm pushing a patch to warn on selecting symbols
> > with unmet dependencies so that you can select further symbols (manual
> > solving). The patch is in linux-next but you also can grab it from:
> >
> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
>
> 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.

Instead of (or in addition to) warning for incomplete
dependencies, I'd much prefer if the prerequisites were recursively
selected automatically. This way if some options are moved inside a
submenu at some point with a config symbol for that subcategory
(e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
submodules that are required for some driver to work, then my
config will still be fine.

For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
smart enough to notice and automatically enable CONFIG_MTD and
CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.


Nicolas
 |  Next  |  Last
Pages: 1 2
Prev: Kconfig: Enable Kconfig fragments to be used for defconfig
Next: AT91 NOMMU fails to compile 2.6.35-rc5