From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antti Kantee Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Wed, 18 Mar 2015 22:07:39 +0000 Message-ID: <5509F72B.8010304@iki.fi> References: <20150317142907.GD27314@zion.uk.xensource.com> <20150318112014.GC17247@nodbug.moloch.sk> <4558D0C0-8058-4052-994C-6138406CEB35@recoil.org> <5509DEB5.8060906@iki.fi> <21C9D78E-641F-46B7-9820-0C6426B533A1@recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21C9D78E-641F-46B7-9820-0C6426B533A1@recoil.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Anil Madhavapeddy Cc: David Scott , Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , Richard Mortier , xen-devel@lists.xen.org, rumpkernel-users@freelists.org, Thomas Gazagnaire , Anthony PERARD , Martin Lucina List-Id: xen-devel@lists.xenproject.org On 18/03/15 21:21, Anil Madhavapeddy wrote: >> This is not an argument for or against; if you want to expose AF_WHATEVER to applications running on a rump kernel, you need to sell AF_WHATEVER to NetBSD, not to rumpkernel-users. Well, preferably you need to sell it to everyone implementing sockets and running on some sort of hypervisor, but of course gotta start from somewhere. > > Given that most of the uses of this will be in userspace code, just > faking out AF_UNIX in Rump does seem a lot easier. It doesn't matter > to MirageOS either way -- we just need a well-defined XenStore/ring > protocol to obey to do connection setup on the other side. Where do you propose to inject that faking out (and what does it even mean)? Someone at Berkeley decided that socket drivers should be globally enumerated, and PF_UNIX leads to exactly one handler. Just hacking hooks as local patches into the PF_UNIX driver is against the whole point of having unmodified, tested drivers from upstream. So, if you want your bus to appear as a socket to userspace, I don't see any shortcut to not going via NetBSD. If you're happy with something else than a socket, that's another story. Especially if the interface doesn't matter too much for whatever purpose you plan to use it for, it's silly to specify the interface so that the implementation process is as convoluted as possible ;)