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

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw



On Wed, 2015-11-04 at 16:50 +0000, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the
> macro set_xen_guest_handle_raw"):
> > All quite interesting, but pretty moot with there not being any
> > get_xen_guest_handle() anymore.
> 
> If we don't provide a get_xen_guest_handle, a kernel developer will be
> sorely tempted to make one.
> 
> If they do and they write it in the obvious way, then the compiler
> could `deduce' that the top part of the uint64_t store was dead, and
> eliminate it.

I realise that "correct use of unions" here is orthogonal to "using gcc
extensions", but trying to achieve the former while avoiding the later
is having a multiplicative effect on the complexity of the resulting
macros, so:...

Realistically any OS which did try and implement this would probably
not try and jump through such hoops in order to do it in pure ANSI-C
but would instead just use whatever extension their compiler provided
to make it easier to write such macros (such as typeof).

Perhaps we should follow the lead ofÂxen/include/public/io/ring.h here
and provide a clear, readable and correct version under #if __GNUC__
(which our own tools build would use) using the extensions and an
alternative ANSI-C only one which might have short comings e.g. in
efficiency, maybe evaluating the argument more than once, etc but not
in correctness.

Realistically IMHO the #else case could be "#error you need to
implement this carefully" but I suspect others will not be comfortable
with that approach.

Ian.

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