Network Stack Cloning Updates on FreeBSD 56
Dan writes "Network stack cloning patches on FreeBSD allow for multiple fully independent network stacks to simultaneously coexist in a single FreeBSD kernel. Marko Zec has prepared a latest snapshot of the patches (against 4.8-RELEASE). The latest snapshot includes (a) internal restructuring - - struct vimage is now separated in resource-specific containers, and (b) Kernel message buffers - each vimage / vprocg now has a private kernel message buffer instance. Julian Elischer gave a talk on this subject at the USENIX Annual Technical Conference (FreeNIX track) in San Antonio, TX, June 2003. Marko's slides were presented at BSDCon Europe 2002 in Amsterdam."
Very nice, but can it use another machine's nic? (Score:5, Interesting)
It is even possible in plan9 to use the network stack of a remote machine as your own.
Using sshnet [bell-labs.com] one can do "sshnet remote_host" then all subsequent network activity for the current process group and any children will use the remote hosts' network stack as though it were local.
In this way one can run tcp listeners on a remote machine (on IP N) that deny requests from anything but the IP N and leave SSH as the only external listener. No special tunnelling hoops to jump through.
Monolithic kernels are dying.
Re:Very nice, but can it use another machine's nic (Score:3, Insightful)
one hasn't truly lived until they've done an:
import somewhere.far.away
Re:Very nice, but can it use another machine's nic (Score:2)
Your wish has been granted... actually it was around more than a decade ago.
Check out QNX, you can use other QNX machine's network (and other devices, including audio, graphics, block devices etc) as your own local ones!!! And no silly imports etc... they just work!
Re:Very nice, but can it use another machine's nic (Score:2)
And it really means _everything_, not only devices. Check out this MPI implementation using remotely served and imported _pipes_:
message passing for Plan 9 [ucalgary.ca]
Re:Very nice, but can it use another machine's nic (Score:5, Informative)
We're talking about a different level of abstraction, here. After all, from the OS's perspective, how can Plan9 "use the network stack of a remote machine" except via the network stack of the local machine? Nothing short of magic will let a machine "use another machine's nic" except via packets sent through its own. Yes, Plan9 supports user namespaces that allows network interfaces to be virtualized, but that's from the perspective of what BSD calls "userland" -- which is only partly related to what the article discusses.
This facility is about allowing multiple networks stacks from the kernel's perspective. Not just the illusion of separate stacks as seen from userland (though it certainly provides that, too). These stacks can then be treated independently from the perspective of packet filtering, traffic shaping, and so on, as well as providing a "virtual machine" from a user's perspective. This isn't to say that Plan9's capabilities aren't useful or interesting, especially from a theoretical perspective. But Plan9 has different goals than an OS like FreeBSD that first and foremost is designed to be used as on server in a datacenter. Thus the perspective is more along the lines of machine virtualization and really has little to do with Plan9's concept of a namespace.
Jail (Score:2)
Rus
I GLANCED at the paper (Score:2)
What are some concrete uses of this technology?
TIA
Re:I GLANCED at the paper (Score:4, Interesting)
The article says jails will have full control over a virtual stack. Soo... We can now have full firewall control under a jail, now that would make my life at LEAST twice as fun!
Re:I GLANCED at the paper (Score:2)
Could you give me just one example of a use case for this?
Thanks!
Re:I GLANCED at the paper (Score:2, Interesting)
Re:I GLANCED at the paper (Score:2)