Messages in this thread | | | Date | Fri, 25 Jun 2004 11:04:13 +0200 | From | Lars Marowsky-Bree <> | Subject | Re: RFC: Testing for kernel features in external modules |
| |
On 2004-06-25T10:32:22, Andreas Gruenbacher <agruen@suse.de> 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:
- if the vendor backports a given feature + API from mainstream, the define can be set to match the mainstream version; - If vendor introduces a vendor API extension, the vendor extension would come into play. - If the vendor API eventually merges with the mainstream API again, the vendor define goes away again and rule 1 applies.
This should age pretty well - as soon as an external code tree drops support for a given version, they can clean out all the #ifdefs they had based on this.
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.
Sincerely, Lars Marowsky-Brée <lmb@suse.de>
-- High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs, Research and Development | try again. fail again. fail better. SUSE LINUX AG - A Novell company \ -- Samuel Beckett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |