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

[Xen-devel] specifying evtchn ports?

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "King, Steven R" <steven.r.king@xxxxxxxxx>
  • Date: Tue, 11 Oct 2005 17:04:57 -0700
  • Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 12 Oct 2005 00:05:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcXORACIiy2kmiktQViU2Vt1IQFf3gAdnvVA
  • Thread-topic: specifying evtchn ports?

Your response helped, thanks.

Is the intent that userland cannot specify an event channel port number?
If so, is xen-store the proper way to communicate a port value between
domains?  The latest event channel code appears to always allocate a
free port on behalf of the caller for both sides of an interdomain
channel.  Older versions allowed the unbound end to specify a port

Regarding port types:

Xen uniformly uses "int" for ports and computes port numbers < 0 as
invalid.  This is all great.  Userland code could be more consistent by
also using "int" throughout.  Using u32 throughout usermode creates
problems for functions with overloaded +port/-error return values.  Any
interest here?

Thanks for the help,

-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
Sent: Tuesday, October 11, 2005 2:18 AM
To: King, Steven R
Cc: xen-devel List
Subject: Re: [Xen-devel] suggested event channel cleanups

On 10 Oct 2005, at 23:50, King, Steven R wrote:

> This patch standardizes the type of "port" to "int" for event channel 
> functions and structures.  Internally, Xen is using "int" for ports, 
> but userland code has a mix of "int" and "u32".  Type "int" is 
> preferred in userland, since some functions want to return a positive 
> port value or a negative error code.

Userspace may do this, but Xen doesn't. It makes sense to give those
fields an unsigned type because Xen will never return a negative value. 
If higher-level interfaces outside Xen return a signed type, with -ve
indicating error, there's no reason for Xen to do the same.

> xenctrl.h: Added extern "C" to allow linking with C++ programs.

Isn't it quite normal to put the ''extern "C"' in the C++ program itself
when including C header files?

> xenctrl.h: Added function prototype for event channel close.
> xenctrl.h: Added function prototype for interdomain event channel.

These were removed last week.; The correct interface for user-space
programs is now ioctls via /dev/xen/evtchn. See examples of its use in
console/daemon/io.c, for example.

> I've never offered up a patch before, so apologies if I'm abusing 
> conventions.

There's nothing wrong with the format of the patch. :-)

  -- Keir

Xen-devel mailing list



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