Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel

[Antti Kantee <pooka@xxxxxx>]

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 ;)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel