LKML Archive on
help / color / mirror / Atom feed
From: David Brownell <>
To: "Jan Beulich" <>
Cc: "Randy Dunlap" <>,
	"lkml" <>
Subject: Re: 2.6.23-git Kconfig regression
Date: Wed, 16 Jan 2008 16:02:01 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

  reply	other threads:[~2008-01-17  0:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-20  1:22 David Brownell
2007-10-20  1:46 ` Randy Dunlap
2007-10-20  1:57   ` David Brownell
2007-10-20  2:01     ` Randy Dunlap
2007-10-20  2:55       ` Randy Dunlap
2007-10-20  3:21         ` Randy Dunlap
2007-10-20  4:11           ` David Brownell
2007-10-20  4:25             ` Linus Torvalds
2007-10-20 16:50               ` Sam Ravnborg
2008-01-16  9:29           ` Jan Beulich
2008-01-17  0:02             ` David Brownell [this message]
2008-01-17  8:16               ` Jan Beulich
2008-01-17  8:32                 ` David Brownell
2007-10-20 18:27 Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: 2.6.23-git Kconfig regression' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).