On 05/07/2019 13:13, Paul Durrant wrote: >> -----Original Message----- > [snip] >> I'm completely on Jan's side here. >> >> What would be possible perhaps is to split ring.h into two headers: a >> new one with the pure ring definitions and ring.h #include-ing >> xen-compat.h and the new header and #define-ing the xen*mb() macros. >> >> Not sure this would be worth it, though. >> > Ok. Probably not worth it, as you say. If we don't feel comfortable remove > old cruft like these then projects importing the headers will just have to > hack it or live with importing xen-compat too. Anthony already submitted a > patch doing the former for QEMU.
Look. Either we expect people to copy the headers, or we expect to have a single canonical copy which is up to date and always backwards compatible. All documentation says "take a copy of the headers", and I have never seen anything, except the rather weird 2.6.18 driver port in tree, use the headers verbatim. These headers describe an ABI, not an API. Sure - the API is by convention but by the time people have taken a copy, they really are free to make modifications as they see fit, as long as they don't change the ABI. Insisting that everyone take a copy, *and* maintaining API compatibility for obsolete cruft is an exercise in self-flagilation. Given there are zero current consumers that we know of using the headers in a verbatim way, and all we're talking about is some pieces which really should never have been present in the first place, I think its entirely reasonable to make some changes and release note them. Xen 4.13 release: ... * Some obsolete warts in the public headers have been dropped. People syncing to this version should be aware of: 1) ... 2) ... Nothing here is rocket science, is it? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
