[lkml]   [2004]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: Testing for kernel features in external modules
    On Fri, Jun 25, 2004 at 11:04:13AM +0200, Lars Marowsky-Bree wrote:
    > On 2004-06-25T10:32:22,
    > Andreas Gruenbacher <> said:
    > > I disagree. I don't think we want to clutter the code with feature
    > > definitions that have no known users. That doesn't age/scale very
    > > well. It's easy enough to test for features in the external module.
    > True enough, but how do you propose to do that? I do understand the pain
    > of the external module builds who have to try and support the vanilla
    > kernel plus several vendor trees.
    > Yes, of course, we could end up with a autoconf like approach for
    > building them, but ... you know ... that's sort of ugly.
    > Having a list of defines to document the version of a specific API in
    > the kernel, and a set of defines pre-fixed with <vendor>_ to document
    > vendor tree extensions may not be the worst thing:
    > Now the granularity of the API versioning is interesting - per .h is too
    > coarse, and per-call would be too fine. But I'm sure someone could come
    > up with a sane proposal here.

    What's an API for modules?
    - whether a .h file is present under include/
    - every EXPORT_SYMBOL{,_GPL}'ed function
    - every inlined function under include/
    - every struct defined under include/
    - perhaps more things I'm currently forgetting

    Every change to something mentioned above during a development kernel
    needs to be cover by an appropriate API versioning.

    And then consider as an example cases like a function returning
    irqreturn_t in 2.6:
    - in 2.6, this function returns irqreturn_t (typedef'd to int)
    - in 2.4, this function might return irqreturn_t (typedef'd to void)
    - in 2.4, this function might return void

    I'm sure there is a correct solution for such cases - but it's extra
    work and easy to get things wrong.

    Why do you dislike autoconf? I do not pretend autoconf where perfect -
    but it works. Looking at the external ALSA, autoconf seems to be a good
    solution to probe for exact the things a module needs without a big
    overhead in kernel development.

    > Sincerely,
    > Lars Marowsky-Brée <>



    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.024 / U:33.236 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site