specifying evtchn ports?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

specifying evtchn ports?

King, Steven R
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:[hidden email]]
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
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: specifying evtchn ports?

Keir Fraser

On 12 Oct 2005, at 01:04, King, Steven R wrote:

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

Correct, alloc_unbound() and bind_interdomain() both now allocate one
port on behalf of the caller. The caller cannot specify which port that
is.

> 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?

I guess. There isn't much userland code to modify now. There isn;t much
evtchn code left in libxenctrl.

  -- Keir


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel