From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] xencomm: Remove xencomm Date: Fri, 14 Mar 2014 10:27:13 -0400 Message-ID: <532311C1.1040300@oracle.com> References: <1394747718-3079-1-git-send-email-boris.ostrovsky@oracle.com> <5322C3710200007800124105@nat28.tlf.novell.com> <53230DE9.2040809@oracle.com> <1394806236.6442.83.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394806236.6442.83.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: keir@xen.org, Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 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 >>>> --- >>>> 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). -boris > > (I haven't decided what I think about keeping vs. ditching the > interfaces, so I make no judgement on that aspect) > > Ian. >