Re: [PATCH] xencomm: Remove xencomm

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 03/14/2014 03:53 AM, Jan Beulich wrote:
>>>> On 13.03.14 at 22:55, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>> Being a feature that has only been used by ia64 and/or ppc it
>> doesn't seem like we need to keep it any longer in the tree.
>>
>> So remove it.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/common/Makefile          |    2 -
>>   xen/common/xencomm.c         |  621 ------------------------------------------
>>   xen/include/Makefile         |    1 -
>>   xen/include/public/xencomm.h |   41 ---
> Just like noted for the removal of the ia64 bits from the public
> headers - I'm not sure removing anything from the public headers
> is ever appropriate. For one, with the implementation going away,
> the interface definitions don't all of the sudden go away too. If
> anyone would ever want to resurrect a deleted architecture, still
> having the old interface definitions in place would point out very
> clearly what compatibility constraints (with regard to the earlier
> implementation) to think about.

If we decide to bring this back the headers will still be available
in source control.

>   And second, the building of the
> unmodified_drivers/ subtree is affected by that removal: IMO
> there's nothing illegitimate to try to build them against a suitable
> (older) kernel, yet mkbuildtree taking the public headers from the
> Xen tree makes it a requirement for the definitions to remain in
> place.

But then we would be building drivers against code (OK, just the headers)
that has not been tested (and more importantly cannot be tested). These
drivers will never run on this version of Xen so it seems to me they should
be built against Xen version that they are expected to be running on.

-boris

>
> Consequently rather than removing further public header bits I
> wonder whether the earlier round of deletions shouldn't be
> undone (as noted in a reply to Olaf's attempt to remove ia64
> bits from unmodified_drivers/, I intentionally avoided mirroring
> these removals to linux-2.6.18-xen.hg).
>
> But of course, if others are of different opinion, then it wouldn't
> make sense to refuse applying Olaf's patch...