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