xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Antti Kantee <pooka@iki.fi>
To: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
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	[thread overview]
Message-ID: <55795C77.8080808@iki.fi> (raw)
In-Reply-To: <20150610161509.GH14606@zion.uk.xensource.com>

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.

      reply	other threads:[~2015-06-11 10:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 11:36 [PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library Ian Campbell
2015-06-11 11:20   ` Andrew Cooper
2015-06-11 11:35     ` Ian Campbell
2015-06-11 12:06       ` Jan Beulich
2015-06-11 12:21         ` Ian Campbell
2015-09-21 16:17     ` Ian Jackson
2015-09-21 17:03       ` Andrew Cooper
2015-09-21 17:13         ` Ian Jackson
2015-09-21 17:30           ` Andrew Cooper
2015-09-22  8:39             ` Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 2/6] tools: Link in-tree libvchan users against libxenvchan.so Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 3/6] tools: Do not add top-level tools dir to include path Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 4/6] tools/libxc: Remove osdep indirection for xc_evtchn Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 5/6] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn Ian Campbell
2015-06-10 16:29   ` David Vrabel
2015-06-11  8:58     ` Ian Campbell
2015-06-10 17:16   ` Andrew Cooper
2015-06-11  9:03     ` Ian Campbell
2015-06-10 11:36 ` [PATCH RFC tools 6/6] Cleanup SHLIBDEPS Ian Campbell
2015-06-10 11:37 ` [PATCH RFC qemu-trad 1/2] qemu-xen-traditional: Use xentoollog as a separate library Ian Campbell
2015-06-10 15:57   ` Ian Jackson
2015-06-11  8:59     ` Ian Campbell
2015-06-10 11:37 ` [PATCH RFC qemu-trad 2/2] qemu-xen-traditional: Use libxenevtchn Ian Campbell
2015-06-10 11:37 ` [PATCH RFC mini-os 1/2] mini-os: Include libxentoollog with libxc Ian Campbell
2015-06-10 11:37 ` [PATCH RFC mini-os 2/2] mini-os: Include libxenevtchn " Ian Campbell
2015-06-10 16:01 ` [PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries Ian Jackson
2015-06-10 16:15   ` Wei Liu
2015-06-11 10:01     ` Antti Kantee [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55795C77.8080808@iki.fi \
    --to=pooka@iki.fi \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).