On Thursday 28 January 2010, Arnd Bergmann wrote: > On Wednesday 27 January 2010, Sridhar Samudrala wrote: > > On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote: > > > On Wednesday 27 January 2010, Anthony Liguori wrote: > > > > >> I think -net socket,fd should just be (trivially) extended to work > > > > >> with raw sockets out of the box, with no support for opening it. > > > > >> Then you can have libvirt or some wrapper open a raw socket and a > > > > >> private namespace and just pass it down. > > > > > > > > > > That'd work. Anthony? > > > > > > > > The fundamental problem that I have with all of this is that we > > > > should not be introducing new network backends that are based around > > > > something only a developer is going to understand. If I'm a user and > > > > I want to use an external switch in VEPA mode, how in the world am I > > > > going to know that I'm supposed to use the -net raw backend or the > > > > -net socket backend? It might as well be the -net butterflies > > > > backend as far as a user is concerned. > > > > > > My point is that we already have -net socket,fd and any user that > > > passes an fd into that already knows what he wants to do with it. > > > Making it work with raw sockets is just a natural extension to this, > > > which works on all kernels and (with separate namespaces) is reasonably > > > secure. > > > > Didn't realize that -net socket is already there and supports TCP and > > UDP sockets. I will look into extending -net socket to support AF_PACKET > > SOCK_RAW type sockets. > > Actually, Jens had a patch doing this in early 2009 already but we > decided to not send that one out at the time after Or had sent his > version of the raw socket interface, which was a superset. Maybe Jens > can post his patch again if that still applies? It's been a while since I last looked at it. I think it will need a bitt massaging before it will apply again. Jens -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html