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