Hi Arjan.
>>> I actually much prefer to tell people that they have to
>>> recompile their modules if they change the type of their
>>> kernel.
>> This is actually something for the Makefile and config
>> hackers to ponder actually: being able to pack a 2.4 extra
>> module as source so that the end user (or their rpm, dpkg,
>> slp,... tools) can type Make and the Make script can grab
>> all the needed config from the kernel .config and module
>> syms that are already present
> For 2.5 I have something like this in mind: (this is a
> first draft of what I think we need)
> Every "driver" specifies the following information:
> * the CONFIG_variable
Yes.
> * 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.
> * the type (bool tristate Hex String etc)
Some of the existing types really need splitting up into multiple
types. Specifically, `hex` really needs to be split into `byte`,
`word`, etc.
> Optional:
> * 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'.
The others are all reasonable except for possible language
dependance.
> This is a lot of information, and perhaps it should be
> stored in XML or a similar format. 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.
> 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.
> 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.
> This is perhaps overkill (I fear so), but I doubt the
> current Config.in system is flexible enough to allow the
> 3rd requirement to just untar and work.
The current Makefile and config.in systems require that any
subdirectories be explicitly named before they can be compiled,
and the above requirement doesn't fit in with that.
However, it shouldn't be difficult to tweak the current setup
to deal with this issue.
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:35 EST