Re: [Xen-devel] [PATCH] xencomm: Remove xencomm

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.14 at 15:27, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 03/14/2014 10:10 AM, Ian Campbell wrote:
>> On Fri, 2014-03-14 at 10:10 -0400, Boris Ostrovsky wrote:
>>> On 03/14/2014 03:53 AM, Jan Beulich wrote:
>>>>>>> On 13.03.14 at 22:55, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> 
>>>>>>> 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@xxxxxxxxxx>
>>>>> ---
>>>>>    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.
>> But PV drivers don't "run on Xen", they run against a backend in another
>> guest. There is absolutely no need to build your drivers for a
>> particular version of Xen.
> 
> Right, I meant in the guest that runs on this version of Xen.
> 
> And I agree that it may not be necessary to build drivers against a 
> particular
> Xen version but it seems to me a bit odd to do it against a version that is
> known to never be usable with this driver (via a guest).

But this isn't building against a particular version of Xen at all, it's
just building with the most recent interface definitions (which are
required to remain backward compatible anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel