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

Re: [Xen-devel] [PATCH v2 09/18] OvmfPkg/XenBusDxe: Add Event Channel Notify.



On Wed, Sep 10, 2014 at 04:15:03PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 04, 2014 at 05:51:04PM +0100, Anthony PERARD wrote:
> > This first function is used to notify the other side that there is
> > something to do. The other side is another Xen domain.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > 
> > ---
> > Change in V2:
> > - file header
> > - coding style
> > - adding comment to functions
> > - Licenses
> > ---
> >  OvmfPkg/XenBusDxe/EventChannel.c | 49 
> > +++++++++++++++++++++++++++++++++++++++
> >  OvmfPkg/XenBusDxe/EventChannel.h | 50 
> > ++++++++++++++++++++++++++++++++++++++++
> >  OvmfPkg/XenBusDxe/XenBusDxe.inf  |  2 ++
> >  3 files changed, 101 insertions(+)
> >  create mode 100644 OvmfPkg/XenBusDxe/EventChannel.c
> >  create mode 100644 OvmfPkg/XenBusDxe/EventChannel.h
> > 
> > diff --git a/OvmfPkg/XenBusDxe/EventChannel.c 
> > b/OvmfPkg/XenBusDxe/EventChannel.c
> > new file mode 100644
> > index 0000000..f34f9b8
> > --- /dev/null
> > +++ b/OvmfPkg/XenBusDxe/EventChannel.c
> > @@ -0,0 +1,49 @@
> > +/** @file
> > +  Event Channel function implementation.
> > +
> > +  Event channel are use to notify of an event that happend in a shared
> > +  structure for example.
> > +
> > +  Copyright (C) 2014, Citrix Ltd.
> > +
> > +  Redistribution and use in source and binary forms, with or without
> > +  modification, are permitted provided that the following conditions
> > +  are met:
> > +
> > +  * Redistributions of source code must retain the above copyright
> > +    notice, this list of conditions and the following disclaimer.
> > +  * Redistributions in binary form must reproduce the above copyright
> > +    notice, this list of conditions and the following disclaimer in
> > +    the documentation and/or other materials provided with the
> > +    distribution.
> > +
> > +  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > +  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > +  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> > +  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> > +  COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> > +  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> > +  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > +  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > +  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> > +  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
> > +  ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> > +  POSSIBILITY OF SUCH DAMAGE.
> > +
> > +**/
> > +#include "EventChannel.h"
> > +#include "XenHypercall.h"
> > +
> > +VOID
> > +XenEventChannelNotify (
> > +  IN XENBUS_DEVICE *Dev,
> > +  IN evtchn_port_t Port
> > +  )
> > +{
> > +  INTN ReturnCode;
> > +  evtchn_send_t Send;
> > +
> > +  Send.port = Port;
> > +  ReturnCode = XenHypercallEventChannelOp (Dev, EVTCHNOP_send, &Send);
> > +  ASSERT (ReturnCode == 0);
> 
> Ouch. How about returning the return code. For example it might be -EINVAL
> due to the port value being wrong (or not yet set). Shouldn't the caller
> decided whether to ASSERT at that point?

Yes. I will fix that.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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