(Originally posted to kbuild-devel per MAINTAINERS, but
that post was rejected since that is -- undocumented,
sigh -- a members-only list.)
Hi,
I noticed a regression, visible in the drivers/usb/gadget Kconfig;
it seems to be quite recent.
That Kconfig hasn't changed (other than adding new drivers), and
it's worked that way for several years now ... so the issue seems
to be changes in menuconfig/kconfig/etc semantics.
The issue is that when USB_GADGET=m, it's no longer possible to
configure peripheral controller drivers as modules ... the controller
drivers can now only be configured for static linkage.
It should be making a choice of one of the controller drivers which
could work on the target system, and allow that driver to be linked
either as a module (ok iff USB_GADGET=m) or statically.
What's the deal here?
- Dave
On Fri, 19 Oct 2007 18:22:45 -0700 David Brownell wrote:
> (Originally posted to kbuild-devel per MAINTAINERS, but
> that post was rejected since that is -- undocumented,
> sigh -- a members-only list.)
That mailing list is no longer used. Today's git pull for kbuild
included this change:
KCONFIG
P: Roman Zippel
M: [email protected]
-L: [email protected]
+L: [email protected]
S: Maintained
> Hi,
>
> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> it seems to be quite recent.
>
> That Kconfig hasn't changed (other than adding new drivers), and
> it's worked that way for several years now ... so the issue seems
> to be changes in menuconfig/kconfig/etc semantics.
>
> The issue is that when USB_GADGET=m, it's no longer possible to
> configure peripheral controller drivers as modules ... the controller
> drivers can now only be configured for static linkage.
>
> It should be making a choice of one of the controller drivers which
> could work on the target system, and allow that driver to be linked
> either as a module (ok iff USB_GADGET=m) or statically.
>
> What's the deal here?
Hm, it does look very odd. It looks like it has something to
do with <choice> working differently for some reason.
In xconfig, I set all of the View Options and when I click on one
of the periph. controllers, it says
depends on =y && PCI
but if I back up to -git7, it says
depends on <choice> && PCI
I'll keep looking.
---
~Randy
> > (Originally posted to kbuild-devel per MAINTAINERS, but
> > that post was rejected since that is -- undocumented,
> > sigh -- a members-only list.)
>
> That mailing list is no longer used. Today's git pull for kbuild
> included this change:
>
> KCONFIG
> P: Roman Zippel
> M: [email protected]
> -L: [email protected]
> +L: [email protected]
> S: Maintained
I hadn't pulled that one yet... ;)
> > I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> > it seems to be quite recent.
> >
> > ...
>
> Hm, it does look very odd. It looks like it has something to
> do with <choice> working differently for some reason.
>
> In xconfig, I set all of the View Options and when I click on one
> of the periph. controllers, it says
>
> depends on =y && PCI
That's what I saw too. Looked dubious ...
> but if I back up to -git7, it says
>
> depends on <choice> && PCI
And that git7 thing doesn't look _quite_ so odd. Did git7 actually
let you configure a modular GOKU (for example), i.e. work correctly?
> I'll keep looking.
Thanks. Kconfig is one of the areas I prefer to let others
be the experts. :)
- Dave
David Brownell wrote:
>>> (Originally posted to kbuild-devel per MAINTAINERS, but
>>> that post was rejected since that is -- undocumented,
>>> sigh -- a members-only list.)
>> That mailing list is no longer used. Today's git pull for kbuild
>> included this change:
>>
>> KCONFIG
>> P: Roman Zippel
>> M: [email protected]
>> -L: [email protected]
>> +L: [email protected]
>> S: Maintained
>
> I hadn't pulled that one yet... ;)
>
>
>>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
>>> it seems to be quite recent.
>>>
>>> ...
>> Hm, it does look very odd. It looks like it has something to
>> do with <choice> working differently for some reason.
>>
>> In xconfig, I set all of the View Options and when I click on one
>> of the periph. controllers, it says
>>
>> depends on =y && PCI
>
> That's what I saw too. Looked dubious ...
>
>
>> but if I back up to -git7, it says
>>
>> depends on <choice> && PCI
>
> And that git7 thing doesn't look _quite_ so odd. Did git7 actually
> let you configure a modular GOKU (for example), i.e. work correctly?
Yes, -git9 does.
Looks to me like it broke on -git10. -git9 is OK.
>> I'll keep looking.
>
> Thanks. Kconfig is one of the areas I prefer to let others
> be the experts. :)
--
~Randy
On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
> >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> >>> it seems to be quite recent.
> >>>
> >>> ...
> >> Hm, it does look very odd. It looks like it has something to
> >> do with <choice> working differently for some reason.
> >>
> >> In xconfig, I set all of the View Options and when I click on one
> >> of the periph. controllers, it says
> >>
> >> depends on =y && PCI
> >
> > That's what I saw too. Looked dubious ...
> >
> >
> >> but if I back up to -git7, it says
> >>
> >> depends on <choice> && PCI
> >
> > And that git7 thing doesn't look _quite_ so odd. Did git7 actually
> > let you configure a modular GOKU (for example), i.e. work correctly?
>
> Yes, -git9 does.
>
> Looks to me like it broke on -git10. -git9 is OK.
>
> >> I'll keep looking.
> >
> > Thanks. Kconfig is one of the areas I prefer to let others
> > be the experts. :)
[hm, odd email problems, changing SMTP]
David,
Just a small update.
If I set USB gadget support to Y instead of M and peripheral
controller menu item to Y instead of M, then I can select any of the
4 periph. controllers that are available to me. (on -git14)
I don't know why it's like this though.
---
~Randy
On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
> On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
>
> > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> > >>> it seems to be quite recent.
> > >>>
> > >>> ...
> > >> Hm, it does look very odd. It looks like it has something to
> > >> do with <choice> working differently for some reason.
> > >>
> > >> In xconfig, I set all of the View Options and when I click on one
> > >> of the periph. controllers, it says
> > >>
> > >> depends on =y && PCI
> > >
> > > That's what I saw too. Looked dubious ...
> > >
> > >
> > >> but if I back up to -git7, it says
> > >>
> > >> depends on <choice> && PCI
> > >
> > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually
> > > let you configure a modular GOKU (for example), i.e. work correctly?
> >
> > Yes, -git9 does.
> >
> > Looks to me like it broke on -git10. -git9 is OK.
> >
> > >> I'll keep looking.
> > >
> > > Thanks. Kconfig is one of the areas I prefer to let others
> > > be the experts. :)
>
> [hm, odd email problems, changing SMTP]
>
> David,
>
> Just a small update.
>
> If I set USB gadget support to Y instead of M and peripheral
> controller menu item to Y instead of M, then I can select any of the
> 4 periph. controllers that are available to me. (on -git14)
> I don't know why it's like this though.
David,
My (quick, meaning that I may have missed something) testing
indicates that the problem is in the patches attached.
Can you revert them and test that?
>From git:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923
Change kconfig behavior so that mixing bool and tristate config settings in
a choice is possible and has the desired effect of offering just the
tristate options individually if the choice gets set to M, and a normal
boolean selection if the choice gets set to Y.
Odd, I don't recall seeing this patch...
---
~Randy
> My (quick, meaning that I may have missed something) testing
> indicates that the problem is in the patches attached.
Yes, reverting this seems to resolve the problem:
> a5bf3d891a6a0fb5aa122792d965e3774108b923
>
> Change kconfig behavior so that mixing bool and tristate config settings in
> a choice is possible and has the desired effect of offering just the
> tristate options individually if the choice gets set to M, and a normal
> boolean selection if the choice gets set to Y.
Reverting this patch also fixes a second problem that I didn't
mention: various dependent options couldn't be enabled.
Again in drivers/usb/gadget/Kconfig, examples include the
ability to configure the Ethernet gadget to act as an RNDIS
peripheral; or enabling Mass Storage gadget debug options.
Good sleuthing, and thanks!
Now we just need to see that patch reverted before RC1... I don't
know how Linus deals with all his LKML mail, so I cc'd him in
the hope that direct messages get through a bit faster.
- Dave
On Fri, 19 Oct 2007, David Brownell wrote:
> > My (quick, meaning that I may have missed something) testing
> > indicates that the problem is in the patches attached.
>
> Yes, reverting this seems to resolve the problem:
>
> > a5bf3d891a6a0fb5aa122792d965e3774108b923
> >
> > Change kconfig behavior so that mixing bool and tristate config settings in
> > a choice is possible and has the desired effect of offering just the
> > tristate options individually if the choice gets set to M, and a normal
> > boolean selection if the choice gets set to Y.
>
> Reverting this patch also fixes a second problem that I didn't
> mention: various dependent options couldn't be enabled.
>
> Again in drivers/usb/gadget/Kconfig, examples include the
> ability to configure the Ethernet gadget to act as an RNDIS
> peripheral; or enabling Mass Storage gadget debug options.
>
>
> Good sleuthing, and thanks!
>
> Now we just need to see that patch reverted before RC1... I don't
> know how Linus deals with all his LKML mail, so I cc'd him in
> the hope that direct messages get through a bit faster.
Ok, I'll revert it, but wanted to make sure that the parties that pushed
the change are aware of this.
Linus
Jan - I assume you will look into this.
And thanks to David/Randy for narrowing this down.
Thanks,
Sam
On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 19 Oct 2007, David Brownell wrote:
>
> > > My (quick, meaning that I may have missed something) testing
> > > indicates that the problem is in the patches attached.
> >
> > Yes, reverting this seems to resolve the problem:
> >
> > > a5bf3d891a6a0fb5aa122792d965e3774108b923
> > >
> > > Change kconfig behavior so that mixing bool and tristate config settings in
> > > a choice is possible and has the desired effect of offering just the
> > > tristate options individually if the choice gets set to M, and a normal
> > > boolean selection if the choice gets set to Y.
> >
> > Reverting this patch also fixes a second problem that I didn't
> > mention: various dependent options couldn't be enabled.
> >
> > Again in drivers/usb/gadget/Kconfig, examples include the
> > ability to configure the Ethernet gadget to act as an RNDIS
> > peripheral; or enabling Mass Storage gadget debug options.
> >
> >
> > Good sleuthing, and thanks!
> >
> > Now we just need to see that patch reverted before RC1... I don't
> > know how Linus deals with all his LKML mail, so I cc'd him in
> > the hope that direct messages get through a bit faster.
>
> Ok, I'll revert it, but wanted to make sure that the parties that pushed
> the change are aware of this.
>
> Linus
I'll try to, but it may take some time. Jan
>>> Sam Ravnborg <[email protected]> 10/20/07 6:50 PM >>>
Jan - I assume you will look into this.
And thanks to David/Randy for narrowing this down.
Thanks,
Sam
On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 19 Oct 2007, David Brownell wrote:
>
> > > My (quick, meaning that I may have missed something) testing
> > > indicates that the problem is in the patches attached.
> >
> > Yes, reverting this seems to resolve the problem:
> >
> > > a5bf3d891a6a0fb5aa122792d965e3774108b923
> > >
> > > Change kconfig behavior so that mixing bool and tristate config settings in
> > > a choice is possible and has the desired effect of offering just the
> > > tristate options individually if the choice gets set to M, and a normal
> > > boolean selection if the choice gets set to Y.
> >
> > Reverting this patch also fixes a second problem that I didn't
> > mention: various dependent options couldn't be enabled.
> >
> > Again in drivers/usb/gadget/Kconfig, examples include the
> > ability to configure the Ethernet gadget to act as an RNDIS
> > peripheral; or enabling Mass Storage gadget debug options.
> >
> >
> > Good sleuthing, and thanks!
> >
> > Now we just need to see that patch reverted before RC1... I don't
> > know how Linus deals with all his LKML mail, so I cc'd him in
> > the hope that direct messages get through a bit faster.
>
> Ok, I'll revert it, but wanted to make sure that the parties that pushed
> the change are aware of this.
>
> Linus
>>> Randy Dunlap <[email protected]> 20.10.07 05:21 >>>
Sorry for only now getting back to this.
>On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
>
>> On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
>>
>> > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
>> > >>> it seems to be quite recent.
>> > >>>
>> > >>> ...
>> > >> Hm, it does look very odd. It looks like it has something to
>> > >> do with <choice> working differently for some reason.
>> > >>
>> > >> In xconfig, I set all of the View Options and when I click on one
>> > >> of the periph. controllers, it says
>> > >>
>> > >> depends on =y && PCI
>> > >
>> > > That's what I saw too. Looked dubious ...
>> > >
>> > >
>> > >> but if I back up to -git7, it says
>> > >>
>> > >> depends on <choice> && PCI
>> > >
>> > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually
But it still doesn't look like it ought to be that way. Still, I'll try to make
this display e.g. <choice>=y instead.
>> > > let you configure a modular GOKU (for example), i.e. work correctly?
>> >
>> > Yes, -git9 does.
>> >
>> > Looks to me like it broke on -git10. -git9 is OK.
>> >
>> > >> I'll keep looking.
>> > >
>> > > Thanks. Kconfig is one of the areas I prefer to let others
>> > > be the experts. :)
>>
>> [hm, odd email problems, changing SMTP]
>>
>> David,
>>
>> Just a small update.
>>
>> If I set USB gadget support to Y instead of M and peripheral
>> controller menu item to Y instead of M, then I can select any of the
>> 4 periph. controllers that are available to me. (on -git14)
>> I don't know why it's like this though.
>
>David,
>
>My (quick, meaning that I may have missed something) testing
>indicates that the problem is in the patches attached.
>
>Can you revert them and test that?
>
>From git:
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923
>
>Change kconfig behavior so that mixing bool and tristate config settings in
>a choice is possible and has the desired effect of offering just the
>tristate options individually if the choice gets set to M, and a normal
>boolean selection if the choice gets set to Y.
>
>Odd, I don't recall seeing this patch...
I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really
written properly:
The first choice contains a mixture of boolean and tristate values; all
of the tristate ones are auto-select values (i.e. such with no prompt),
which results in all of them being unavailable when the choice itself is
set to M (the default with the patch - previously, the choice type got
derived from just the first contained value's type, which was clearly
wrong). These prompt-less items should go after the choice (resulting
in the choice to become a boolean one), if they're needed at all (I
think, especially with the intended change, these options are just
pointless except for avoiding
#if defined(CONFIG_...) || defined(CONFIG_..._MODULE)'
in C sources. In that latter case, the choice could become a tristate
one, allowing all of the selections to be built at once as modules
(which really seems to be the way distro kernels would want to use
it) or any one of them to be built in (the current behavior, except
that at present even when using these as a module only a single
one can be selected).
The second choice appears suspicious altogether - is it really that
just any one of these items can be selected to be built into the
kernel? And again, there are items inside that choice that really
seem to belong outside - I think this is an abuse of the choice
construct, which just happened to work when the choice type (as
described above) was derived from only its first contained value.
Bottom line is, in order to suggest an appropriate adjustment to this
Kconfig file I need clarification on its intentions. Meanwhile I'll scan
the tree for other suspicious choices...
Thanks, Jan
On Wednesday 16 January 2008, Jan Beulich wrote:
> >>> Randy Dunlap <[email protected]> 20.10.07 05:21 >>>
>
> Sorry for only now getting back to this.
>
> >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
> >
> ...
>
> I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really
> written properly:
That's orthogonal to whether that patch caused a regression,
of course. The operational semantics have, except when they
were changed, been that it did what it needed to do.
> These prompt-less items should go after the choice (resulting
> in the choice to become a boolean one),
Maybe -- such a change would have been OK as part of the patch
which changed the operational semantics of Kconfig.
For better or worse, operational semantics are most of what we
have to go by here. It would be nice if they were cleanly and
clearly specified, like a Prolog engine ... just a simple little
tristate logic engine, provably correct, with some UI wrappers.
But that's not what we have today.
> these options are just pointless except for avoiding
>
> #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)'
>
> in C sources.
Well, avoiding such error-prone idioms would seem good to me.
They're common enough, and nasty. But that's not why those
mechanisms are there.
> In that latter case, the choice could become a tristate
> one, allowing all of the selections to be built at once as modules
> (which really seems to be the way distro kernels would want to use
> it) or any one of them to be built in (the current behavior, except
> that at present even when using these as a module only a single
> one can be selected).
The requirements are that (a) just one peripheral controller
driver be selectable, and (b) that it be linked either
statically or dynamically. Related, that for the gadget
drivers (c) none may be selected until the peripheral
controller driver they'll be used with is known, and either
(d1) one may be statically linked, or else (d2) any number
may be built as modules, with only one loaded at a time.
This stuff isn't for "distro" kernels; it's for embedded
environments of the "only this hardware exists" sort.
Space matters, and having small code matters. Nobody has
been interested enough in an "embedded distro" model to
provide patches enabling such stuff.
> The second choice appears suspicious altogether - is it really that
> just any one of these items can be selected to be built into the
> kernel?
Yes. We may want to change that requirement at some point,
but as a rule there can be no more than one upstream USB link
in systems certified as USB conformant. Most hardware doesn't
even allow it.
Certainly, *right now* we don't support multiple upstream
links, and that's been true for as long as that driver stack
has existed.
- Dave
> Bottom line is, in order to suggest an appropriate adjustment to this
> Kconfig file I need clarification on its intentions. Meanwhile I'll scan
> the tree for other suspicious choices...
>
> Thanks, Jan
>
>>> David Brownell <[email protected]> 17.01.08 01:02 >>>
>On Wednesday 16 January 2008, Jan Beulich wrote:
>> >>> Randy Dunlap <[email protected]> 20.10.07 05:21 >>>
>>
>> Sorry for only now getting back to this.
>>
>> >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
>> >
>> ...
>>
>> I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really
>> written properly:
>
>That's orthogonal to whether that patch caused a regression,
>of course. The operational semantics have, except when they
>were changed, been that it did what it needed to do.
>
>
>> These prompt-less items should go after the choice (resulting
>> in the choice to become a boolean one),
>
>Maybe -- such a change would have been OK as part of the patch
>which changed the operational semantics of Kconfig.
I simply wasn't aware of dependencies on the hierarchy re-ordering
done inside menu_finalize() within choices, which is what broke this.
And I'm not convinced this hierarchy re-ordering is even fully
consistent in its current shape (i.e. it just happens to work for the
few cases it really is used in).
>>...
>> these options are just pointless except for avoiding
>>
>> #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)'
>>
>> in C sources.
>
>Well, avoiding such error-prone idioms would seem good to me.
>They're common enough, and nasty. But that's not why those
>mechanisms are there.
But nevertheless there are CONFIG_USB_GADGET_* dependencies in
sources. But in a draft re-write of that Kconfig I found an easy way to
keep these anyway, so the point isn't a concern to me anymore.
>> In that latter case, the choice could become a tristate
>> one, allowing all of the selections to be built at once as modules
>> (which really seems to be the way distro kernels would want to use
>> it) or any one of them to be built in (the current behavior, except
>> that at present even when using these as a module only a single
>> one can be selected).
>
>The requirements are that (a) just one peripheral controller
>driver be selectable, and (b) that it be linked either
>statically or dynamically. Related, that for the gadget
>drivers (c) none may be selected until the peripheral
>controller driver they'll be used with is known, and either
>(d1) one may be statically linked, or else (d2) any number
>may be built as modules, with only one loaded at a time.
So I'll keep it that way.
>This stuff isn't for "distro" kernels; it's for embedded
>environments of the "only this hardware exists" sort.
>Space matters, and having small code matters. Nobody has
>been interested enough in an "embedded distro" model to
>provide patches enabling such stuff.
Why not make the whole thing depend on EMBEDDED then? Or is
development for this perhaps being done in non-embedded
environments?
Thanks for the clarification in any case, now I just needs Roman's
opinion on the re-ordering issue in order to come up with a revised
patch.
Jan
On Thursday 17 January 2008, Jan Beulich wrote:
> >This stuff isn't for "distro" kernels; it's for embedded
> >environments of the "only this hardware exists" sort.
> >Space matters, and having small code matters. ?Nobody has
> >been interested enough in an "embedded distro" model to
> >provide patches enabling such stuff.
>
> Why not make the whole thing depend on EMBEDDED then?
Because while its design center is small systems, there's
actually no technical dependency there. The Kconfig for
EMBEDDED also says it's for disabling or tweaking standard
settings ... ergo, not *adding* subsystems or drivers.
Oddly enough, most things that work on small systems can
also be used on bigger ones. :)
- Dave