[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |