From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antti Kantee Subject: Re: [PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries Date: Thu, 11 Jun 2015 10:01:27 +0000 Message-ID: <55795C77.8080808@iki.fi> References: <1433936188.30003.60.camel@citrix.com> <21880.24407.384102.414919@mariner.uk.xensource.com> <20150610161509.GH14606@zion.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: <20150610161509.GH14606@zion.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: Wei Liu , Ian Jackson Cc: Stefano Stabellini , xen-devel , Ian Campbell , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 10/06/15 16:15, Wei Liu wrote: > On Wed, Jun 10, 2015 at 05:01:27PM +0100, Ian Jackson wrote: >> Ian Campbell writes ("[PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries"): >>> [stuff] >> >> Most of this looks good to me. >> >>> As part of this change I've begun to get rid of the osdep interface >>> layer, since it is obsolete and just gets in the way. IIRC there were >>> some tricks being played to use this on rumpkernels to mix and match >>> facilities from xc_minios.c and xc_netbsd.c. >> >> Replacing those tricks with appropriate #ifdefs would be fine. >> > > FYI I think I will write more glue code to make rump kernel to just use > netbsd code, because they don't want to expose underlying minios > functionalities to application level. It's not so much that we outright "don't want to" as "prefer not to". If there's a strong reason, e.g. a measurably significant performance improvement, then we can talk. However, anything calling past the libc interface is dipping into internal interfaces. We make no guarantee about internal interface stability. One good summary of 8 years of rump kernel development would be "lack of compartmentalization always comes back to bite you", so IMO it's better to conceptually maintain separation even where not enforced by a MMU and just make everything go through the guaranteed-stable syscall interfaces.