lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new config system (was 2.3.48 latency stuff)
In article <> you wrote:
> Hi Arjan.


> > * the Question
> > * the long description
> > * the menu location

> If we are looking to do translations to enable different people
> to configure the kernel in their own language, then all three of
> those will need to be language-dependant. They would probably be
> better placed in separate language-dependant files indexed by the
> config variable.

If the XML route is chosen, it would be possible to allow multiple languages
in the description, like:

<description>
This is a test description
</description>
<description lang="de">
Dieses ist einen test Umschreibung
</description>


> > * AskWhen CONFIG_XXX: Only ask when CONFIG_XXX is set (for
> > example, only ask the IRQ when the card itself is
> > selected)

> Some options are only relevant (and therefore only asked) when
> CONFIG_XXX is set to 'm', others only when it is set to 'y' and
> yet others only when it is set to 'n'.

'n' : is handled by "conflicts" instead of "depends"
'm' : is handled just as dep_tristate does now
'y' : I don't know yet.

> > This information allows
> > for: [aka the requirements]

> > 1) full dependency checking

> That is a definite requirement, but should be possible from the
> existing data PROVIDING all IMMEDIATE dependancies are already
> specified.

With the current Config.in system, this is NOT possible. This is, for me,
the most obvious reason something new is needed.


> > 2) display not-yet valid questions (for forward
> > dependencies etc) while hiding irrelevant questions
> > (IRQ values etc)

> I'm not personally convinced this is the right way to go.

Well, if a dependency isn't straightforward, this would help users to get the
question visible, and when the user selects the option, he gets prompted
with the dependency issue.

But of course, the creator of the question must explicitly enable this.


> > 3) a simple untar of a driver into drivers/3rdparty is
> > enough to compile the driver as a module or into the
> > kernel

> This is more of a Makefile issue than a configuration issue,
> although tweaks to both would be needed to get this working.

"tweaks" or "rewrite"? I would guess at least a partial rewrite would be
needed, and if that is the case, I'd prefer to get it right.

Greetings,
Arjan van de Ven


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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.134 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site