Prev: staging/rar_register: depends on PCI
Next: Your Webmail Quota Has Exceeded The Set Quota Please Upgrade
From: James Bottomley on 5 May 2010 20:10
[Sam: I know you don't maintain kbuild anymore, but since you have the
most experience, if you could find time to comment, I'd be grateful]

The select problem is that the kbuild select directive will turn a
symbol on without reference to its dependencies. This, in turn, means
that either selected symbols must select their dependencies, or that
people using select have to be aware of the selected symbol's dependency
and build those dependencies into their symbol (leading to duplication
and the possibility of getting the dependencies out of sync). We use
select for the scsi transport classes, so we run into this problem in
SCSI quite a lot.

I think the correct fix is to make a symbol that selects another symbol
automatically inherit all of the selected symbol's dependencies.

There seems to be a fairly easy way to do this in kbuild. Right at the
moment, select is handled as additional symbol values as the last point
in the symbol tree evaluation process. Instead, what I propose doing is
for every select symbol, we add an extra unconditional default for the
selected symbol of the selecting symbol's current value (this breaks a
possible dependency cycle) and add to the dependencies of the selecting
symbol, the symbol it's currently selecting.

There's one wrinkle to all of this in that the current parser for
default values stops when it finds the first valid (i.e. whose if clause
evaluates to true) default. To make the above scheme work, I need to
modify the default parser so it takes the highest tristate of all the
valid defaults (and bumps m to y for bool).

Does this look acceptable to people? I think it should give the desired
result and has the added benefit that we can then strip the extra select
overlay out of the kbuild system (making the parser slightly simpler).

If this looks like a good idea to people, I think I can code up a quick
patch.

James



--
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: Geert Uytterhoeven on 6 May 2010 02:50
On Wed, May 5, 2010 at 23:49, James Bottomley
<James.Bottomley(a)hansenpartnership.com> wrote:
> [Sam: I know you don't maintain kbuild anymore, but since you have the
> most experience, if you could find time to comment, I'd be grateful]
>
> The select problem is that the kbuild select directive will turn a
> symbol on without reference to its dependencies.  This, in turn, means
> that either selected symbols must select their dependencies, or that
> people using select have to be aware of the selected symbol's dependency
> and build those dependencies into their symbol (leading to duplication
> and the possibility of getting the dependencies out of sync).  We use
> select for the scsi transport classes, so we run into this problem in
> SCSI quite a lot.
>
> I think the correct fix is to make a symbol that selects another symbol
> automatically inherit all of the selected symbol's dependencies.

What if there's a good reason the selected symbol has this dependency?
E.g. it depends on a critical feature not available? Like CONFIG_HAS_IOMEM?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: James Bottomley on 6 May 2010 09:20
On Thu, 2010-05-06 at 08:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 5, 2010 at 23:49, James Bottomley
> <James.Bottomley(a)hansenpartnership.com> wrote:
> > [Sam: I know you don't maintain kbuild anymore, but since you have the
> > most experience, if you could find time to comment, I'd be grateful]
> >
> > The select problem is that the kbuild select directive will turn a
> > symbol on without reference to its dependencies. This, in turn, means
> > that either selected symbols must select their dependencies, or that
> > people using select have to be aware of the selected symbol's dependency
> > and build those dependencies into their symbol (leading to duplication
> > and the possibility of getting the dependencies out of sync). We use
> > select for the scsi transport classes, so we run into this problem in
> > SCSI quite a lot.
> >
> > I think the correct fix is to make a symbol that selects another symbol
> > automatically inherit all of the selected symbol's dependencies.
>
> What if there's a good reason the selected symbol has this dependency?
> E.g. it depends on a critical feature not available? Like CONFIG_HAS_IOMEM?

I don't quite understand the question. If a selected symbol has a
critical dependency which is config'd to N then the build usually
breaks ... that's what I'm calling the select problem. I thought
CONFIG_HAS_IOMEM was usually selected by the architecture, though. In
the new proposal, we wouldn't be able to generate the invalid
configuration in the first place.

James


--
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: Geert Uytterhoeven on 6 May 2010 09:40
On Thu, May 6, 2010 at 15:17, James Bottomley
<James.Bottomley(a)hansenpartnership.com> wrote:
> On Thu, 2010-05-06 at 08:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 5, 2010 at 23:49, James Bottomley
>> <James.Bottomley(a)hansenpartnership.com> wrote:
>> > [Sam: I know you don't maintain kbuild anymore, but since you have the
>> > most experience, if you could find time to comment, I'd be grateful]
>> >
>> > The select problem is that the kbuild select directive will turn a
>> > symbol on without reference to its dependencies.  This, in turn, means
>> > that either selected symbols must select their dependencies, or that
>> > people using select have to be aware of the selected symbol's dependency
>> > and build those dependencies into their symbol (leading to duplication
>> > and the possibility of getting the dependencies out of sync).  We use
>> > select for the scsi transport classes, so we run into this problem in
>> > SCSI quite a lot.
>> >
>> > I think the correct fix is to make a symbol that selects another symbol
>> > automatically inherit all of the selected symbol's dependencies.
>>
>> What if there's a good reason the selected symbol has this dependency?
>> E.g. it depends on a critical feature not available? Like CONFIG_HAS_IOMEM?
>
> I don't quite understand the question.  If a selected symbol has a
> critical dependency which is config'd to N then the build usually
> breaks ... that's what I'm calling the select problem.  I thought
> CONFIG_HAS_IOMEM was usually selected by the architecture, though.  In
> the new proposal, we wouldn't be able to generate the invalid
> configuration in the first place.

Sorry, my fault, -EREPLY_TOO_EARLY_AFTER_WAKEUP.
Upon rereading what you actually wrote, it made complete sense, and my
question didn't.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Michal Marek on 6 May 2010 10:30
On 5.5.2010 23:49, James Bottomley wrote:
> [Sam: I know you don't maintain kbuild anymore, but since you have the
> most experience, if you could find time to comment, I'd be grateful]
>
> The select problem is that the kbuild select directive will turn a
> symbol on without reference to its dependencies. This, in turn, means
> that either selected symbols must select their dependencies, or that
> people using select have to be aware of the selected symbol's dependency
> and build those dependencies into their symbol (leading to duplication
> and the possibility of getting the dependencies out of sync). We use
> select for the scsi transport classes, so we run into this problem in
> SCSI quite a lot.
>
> I think the correct fix is to make a symbol that selects another symbol
> automatically inherit all of the selected symbol's dependencies.
>
> There seems to be a fairly easy way to do this in kbuild. Right at the
> moment, select is handled as additional symbol values as the last point
> in the symbol tree evaluation process. Instead, what I propose doing is
> for every select symbol, we add an extra unconditional default for the
> selected symbol of the selecting symbol's current value (this breaks a
> possible dependency cycle) and add to the dependencies of the selecting
> symbol, the symbol it's currently selecting.

Nice trick :-).


> There's one wrinkle to all of this in that the current parser for
> default values stops when it finds the first valid (i.e. whose if clause
> evaluates to true) default. To make the above scheme work, I need to
> modify the default parser so it takes the highest tristate of all the
> valid defaults (and bumps m to y for bool).

We should check if some Kconfig file doesn't rely on this "first hit"
behavior and fix it to explicitly list the condition for a given
default. Another option would be to add
default SYM1 || SYM2
to a symbol selected by SYM1 and SYM2.


> Does this look acceptable to people? I think it should give the desired
> result and has the added benefit that we can then strip the extra select
> overlay out of the kbuild system (making the parser slightly simpler).
>
> If this looks like a good idea to people, I think I can code up a quick
> patch.

Other than the above, right now I don't see any issues with such approach.

On a related note, I see Vegard's GSoC project to use a sat solver for
kconfig got accepted [1]. Vegard, how is the project progressing?

[1]
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/psu_home/t127230762803

Michal
--
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/
 |  Next  |  Last
Pages: 1 2 3
Prev: staging/rar_register: depends on PCI
Next: Your Webmail Quota Has Exceeded The Set Quota Please Upgrade