[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] bind_interdomain_evtchn_to_irqhandler and Xen 3.1


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Thu, 21 Feb 2008 00:05:24 +1100
  • Delivery-date: Wed, 20 Feb 2008 05:05:55 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchzWJE/prfmU6nDTkOChX5z58gLNwAQHtsvAAnwGNA=
  • Thread-topic: [Xen-devel] bind_interdomain_evtchn_to_irqhandler and Xen 3.1

> 
> Not sure what you mean? Isn't that a kernel symbol? In which case it
has
> nothing to do with a specific version of Xen itself.
> 

Yes. My bad. It's a function that appears to have been introduced
sometime after 3.0.3 (which is around the level of the patches on the
Debian kernels).

I figured it out though. bind_interdomain_evtchn_to_irqhandler appears
to just be a helper function that does a EVTCHNOP_bind_interdomain
followed by a bind_evtchn_to_irqhandler.

The scsi passthrough backend now works against the Debian kernels (I
just compiled it out of tree) and I have written a windows PV frontend
driver for it - my tape drive is identified by windows, although if I
try a firmware upgrade on it it gets a bit upset, and I'm at a different
location to the tape drive so I can't put a tape in to test further.

James


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.