WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0 of 4] aio event fd support to blktap2

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 4] aio event fd support to blktap2
From: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Date: Fri, 29 Jan 2010 02:52:30 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Jan 2010 02:52:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1264761284.2965.4884.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix VMD
References: <patchbomb.1264718262@xxxxxxxxxxxxxxxxxxxxxxx> <1264761284.2965.4884.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-01-29 at 05:34 -0500, Ian Campbell wrote:
> On Thu, 2010-01-28 at 22:37 +0000, Daniel Stodden wrote:
> >   - Does a runtime kernel version check. I guess this code will
> >     need additional cpp magic on BSDs. 
> 
> I guess BSD will need cpp magic regardless of the kernel version check
> since it will have a different interface altogether.

Right now the version check is only done ifdef __linux__, or it falls
back to the poll patch right away. Whatever BSD is precisely running
there, I didn't change much about the ABI tapdisk is using.

> But for the Linux
> version can we not just try eventfd(), check for -ENOSYS and fall back
> to the old way if necessary, instead of hardcoding the kernel version?

That was my initial thought.
Then again eventfd went in before AIO caught up.
Then again-again it's just a minor number in between. It's probably fair
to assume that the number of dom0 kernels out there which are prone to
surprises is quite limited.

> I suppose eventfd is an unlikely candidate for backporting to anything
> older but in general IMHO it's preferable to check for the actual
> functionality you want to use rather than hardcoding version numbers
> etc.

In theory I agree.

I guess the right (tm) way to fix is to convince the libaio maintainer
to add a proper version define somewhere, instead of doing it in
tapdisk. Then let distros fix libaio if they want it. Which they most
probably want anyway.

The objective was to do without for now, and obsolete tools/libaio asap.

The uname() was just to guarantee the least possible amount of unwanted
surprise while doing so.

If the gap is a non-issue, let's remove that bit.
I'm all for smaller code.

Daniel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel