[Xen-devel] specifying evtchn ports?

["King, Steven R" <steven.r.king@xxxxxxxxx>]

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
number.

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,
-steve



-----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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel