Messages in this thread | | | Date | Mon, 20 Mar 2000 21:48:05 +0100 (CET) | From | (Arjan van de Ven) | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
In article <E12X6c5-0003Il-00@the-village.bc.nu> you wrote: >> modules, but as I'm not a big believer in stable binary interfaces anyway >> (binary modules are quite problematic as it is), 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 * the Question * the long description * the menu location * the type (bool tristate Hex String etc)
Optional: * Which architectures * Safe/Sane answer (ie default answer) * URL to the project homepage * "Requires": dependencies on other questions/options * Suggests: related, suggested questions/options * Conflicts: conflicting options * AskWhen CONFIG_XXX: Only ask when CONFIG_XXX is set (for example, only ask the IRQ when the card itself is selected) * "Makefile": lines to add to the Makefile when this driver is selected * Minversion/Maxversion: minimum/maximum version of the kernel the driver works with
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 2) display not-yet valid questions (for forward-dependencies etc) while hiding irrelevant questions (IRQ values etc) 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 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.
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/
| |