Re: 2.6.23-git Kconfig regression

[David Brownell]

On Wednesday 16 January 2008, Jan Beulich wrote:
> >>> Randy Dunlap <rdunlap@xxxxxxxxxxxx> 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
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/