Hi Arjen.
>>> * 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>
Possible, yes - but would it be desirable? There are three points
against doing that, all fairly obvious to me:
1. My experience with translation work has shown that it is far
easier to translate a document when one does not have to
search for the text to be translated.
2. As I've pointed out several times, for the resulting
configuration system to be truely international, it would
need the ability to present a given set of options in
DIFFERENT order in one language to in another. I do not
believe that such would be realistic if all languages are
included in a single file.
3. Having all the descriptions in the one file is going to
result in a massive file, far larger than the current one.
I for one firmly believe that the sheer size of that file
is one of the main reasons why so many options are not
documented - to put it simply, the size thereof just scares
people away, and the documentation gets put in a separate
file that nobody looks at rather than where it belongs.
The only point in favour of putting them all in one file that I
can see is in the fact that it ensures that no one translation
will get separated from the others, and I have to say that such
would be a minor concern to me.
>>> * 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"
So the decision to define CONFIG_FORWARD_KEYBOARD as "y" is
described as conflicting with the decision that the processor is
not little-endian, is it? That's an interesting description.
Have a look in linux-2.3.99-pre1/arch/mips/config.in around line
118 for where that happens...and it's not the only place where
things like that happen either...
> 'm' : is handled just as dep_tristate does now
> 'y' : I don't know yet.
Personally, I would have thought the following made more sense...
AskIf CONFIG_XXX == "m"
AskIf CONFIG_XXX != "n"
...where the condition that enabled the question to be asked is
made explicit.
>>> 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.
That depends how one uses the current Config.in system. I see the
following ways of using it:
1. Treat the Config.in files as being executable scripts.
In this case, no, it is not possible to do the full
dependancy checking that is required.
2. Treat the Config.in files as data files to be read by
a program that performs a dependancy analysis thereon.
In this case, full dependancy checking is possible with
the current data as it stands.
However, I'm not convinced that the current Config.in files
specify all the information required to do a full dependancy
check. This is NOT because of any lack of ability in the existing
language, but because of the simple fact that the complexity of
the configuration task virtually guarantees the presence of
faulty inter-config-option dependancy information therein.
It is this last point that I believe would be addressed by
changing the configuration language, since the change with
virtually guarantee that all dependancy requirements will need
to be re-evaluated, and the faulty dependancies should therefore
be tracked down.
> This is, for me, the most obvious reason something new is
> needed.
To me, it's not even a valid reason.
>>> 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.
This latter point is what makes me suspect this is the wrong way
to go. I'd prefer to see the configuration start by asking the
independant options, basically asking the user what they want of
the system, and then automatically enable whatever dependancies
are required to give them that.
>>> 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.
Personally, as stated above, I believe the existing language in
the Config.in files is sufficient to fully describe the various
dependancies between the various configuration options, and it is
how this information is being used that is wrong rather than the
format of the information itself.
For this reason, I believe "tweaks" to be the correct word here,
as I believe that at worst only minor changes would be required
to the actual data description in the Config.in files to fully
describe the dependancies between them.
One obvious tweak that looks like it would help is the ability
to specify more than one dependancy in the "dep_tristate" and
related options so that, for example, the PARIDE subsystem can
be described as being dependant on both the PARPORT and IDE
options, which I understand to be the true state of affairs.
Best wishes from Riley.
* Copyright (C) 2000, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:37 EST