All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Haskins <gregory.haskins@gmail.com>
To: netdev@vger.kernel.org
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: NET: Questions about supporting older kernel's with kmods
Date: Thu, 19 Nov 2009 09:21:45 -0500	[thread overview]
Message-ID: <4B055479.8070101@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

             reply	other threads:[~2009-11-19 14:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 14:21 Gregory Haskins [this message]
2009-11-19 14:53 ` NET: Questions about supporting older kernel's with kmods Ben Hutchings
2009-11-19 14:59   ` Gregory Haskins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B055479.8070101@gmail.com \
    --to=gregory.haskins@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.