From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v6] vfio: Support for no-IOMMU mode
Date: Thu, 28 Jan 2016 15:00:19 +0000 [thread overview]
Message-ID: <C6ECDF3AB251BE4894318F4E45123697820C54B0@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <2132629.COtjSkm5oU@xps13>
> > Hi Thomas,
> >
> > > 2016-01-28 11:57, Anatoly Burakov:
> > > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 5, 0)
> > >
> > > Why not #ifndef VFIO_NOIOMMU_IOMMU?
> > > It would avoid some backport issue.
> >
> > I don't see how it could. Versions post-4.5 will have
> VFIO_NOIOMMU_IOMMU, so no issue there. Pre-4.5 versions, whether
> they do or do not have VFIO_NOIOMMU_IOMMU defined, will have
> RTE_VFIO_NOIOMMU defined as 8 regardless.
>
> Are we sure it will ever be backported as 8?
> Anyway I think it's better to avoid version number checks.
Is there a precedent of kernel API definitions ever changing in backports? Presumably whoever backports the changes is interested in making them as compatible as possible, so I believe it's a safe bet to make. I have no strong opinion for or against this way of doing things, but if we're taking issue with kernel version checks, we probably should also adapt all the other stuff in the eal_vfio.h that does things in the exact same manner.
> What happens if the feature is reverted from 4.5 as it was from 4.4?
Well then we have to wait until NOIOMMU makes it into official kernel before applying this patch. There's nothing we can do about that. If the patch gets reverted, then defining NOIOMMU as 8 will be wrong regardless of whether there's a kernel version check.
Thanks,
Anatoly
next prev parent reply other threads:[~2016-01-28 15:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 20:16 [dpdk-dev] [PATCH] " Anatoly Burakov
2016-01-13 12:36 ` [dpdk-dev] [PATCH v2] " Anatoly Burakov
2016-01-13 16:45 ` Stephen Hemminger
2016-01-14 9:50 ` Burakov, Anatoly
2016-01-27 9:05 ` Thomas Monjalon
2016-01-27 10:08 ` Burakov, Anatoly
2016-01-27 10:12 ` Thomas Monjalon
2016-01-27 10:24 ` David Marchand
2016-01-27 10:29 ` Burakov, Anatoly
2016-01-27 14:04 ` [dpdk-dev] [PATCH v3] " Anatoly Burakov
2016-01-27 14:23 ` Burakov, Anatoly
2016-01-27 14:32 ` [dpdk-dev] [PATCH v4] " Anatoly Burakov
2016-01-27 15:50 ` Thomas Monjalon
2016-01-27 16:01 ` Burakov, Anatoly
2016-01-27 16:30 ` Burakov, Anatoly
2016-01-27 16:50 ` [dpdk-dev] [PATCH v5] " Anatoly Burakov
2016-01-27 17:07 ` Thomas Monjalon
2016-01-28 10:03 ` Burakov, Anatoly
2016-01-28 13:27 ` Thomas Monjalon
2016-01-28 11:57 ` [dpdk-dev] [PATCH v6] " Anatoly Burakov
2016-01-28 13:58 ` Thomas Monjalon
2016-01-28 14:16 ` Burakov, Anatoly
2016-01-28 14:40 ` Thomas Monjalon
2016-01-28 15:00 ` Burakov, Anatoly [this message]
2016-01-28 16:55 ` Thomas Monjalon
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=C6ECDF3AB251BE4894318F4E45123697820C54B0@IRSMSX109.ger.corp.intel.com \
--to=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).