NET: Questions about supporting older kernel's with kmods
Subsystems (2)
Hi All,
So I was in the process of packaging up my venet driver so that it could not only support the in-tree build (in -next), but also build as a KMP for inclusion in existing distros that already shipped (like SLE, RHEL, CentOS, etc).
The problem I ran into is that the ethtool and netdev_ops components of the in-tree version do not necessarily align with the substrate capabilities of older kernels. What are the best-practices surrounding this issue?
Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key off of, or should I simply look at the kernel version? If the latter, any recommendation on what to use for the aforementioned features? (I can always try to git-annotate to figure it out, but I wonder if there are best-practices already in place).
Q2) Is it considered "bad form" to include such compile-time directives in the version of the code going upstream? E.g. can my driver in -next have "#ifdef CONFIG_HAVE_NETDEV_OPS" or other version/capability deps, or do I need to patch these externally into the code destined for the kmod, and leave the upstream code "pure"?
Thanks in advance,
-Greg
Quoted 7 lines · Gregory Haskins
Hi All,
So I was in the process of packaging up my venet driver so that it could not only support the in-tree build (in -next), but also build as a KMP for inclusion in existing distros that already shipped (like SLE, RHEL, CentOS, etc).
Quoted 7 lines
The problem I ran into is that the ethtool and
netdev_opscomponents of the in-tree version do not necessarily align with the substrate capabilities of older kernels. What are the best-practices surrounding this issue?Q1) Is there any official CONFIG tags (e.g.
HAVE_NETDEV_OPS) I can key off of,
These feature test macros are not consistently provided.
Quoted 1 line
or should I simply look at the kernel version?
That works up to a point, but the 'enterprise' distros backport a lot to earlier kernel versions which can make version tests invalid.
Some out-of-tree/backported drivers use autoconf-style tests, but there is no standard way of doing this.
[...]
Quoted 2 lines
Q2) Is it considered "bad form" to include such compile-time directives in the version of the code going upstream?
[...]
Yes. Don't do that.
Ben.
Signature · 3 lines
Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
Quoted 1 line · Ben Hutchings
On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
[...]
Quoted 5 lines
Quoted 2 lines
or should I simply look at the kernel version?
That works up to a point, but the 'enterprise' distros backport a lot to earlier kernel versions which can make version tests invalid.
Good point
Quoted 4 lines
Some out-of-tree/backported drivers use autoconf-style tests, but there is no standard way of doing this.
Yeah, this might be the only sane way. It turns out that my ETHTOOL issue was trivial. I was missing "#include <linux/ethtool.h>" which worked in upstream, but not in older kernels. So that issue is resolved.
Now I just need to figure out netdev_ops. Perhaps I will just patch the netdev_ops out when building a kmod, since its just
a different way to describe the same thing, and the resulting driver will perform the same.
Quoted 6 lines
[...]
Quoted 2 lines
Q2) Is it considered "bad form" to include such compile-time directives in the version of the code going upstream?
[...]
Yes. Don't do that.
Ok.
Thanks Ben,
-Greg