Re: new IRQ scalability changes in 2.3.48

From: Arjan van de Ven (arjan@fenrus.demon.nl)
Date: Mon Mar 20 2000 - 15:48:05 EST


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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:30 EST