Hi, On Sun, Apr 13, 2008 at 11:53:51PM +0200, zhengda wrote:
> As my understanding, the role of the BPF translator is to work as a > guard between the user and the packet filter in the kernel. Right. As I said, I'm not sure whether it was originally meant as a guard, or only for convenience... But it could be used as guard I believe. > Does this mean that only root user can run pfinet in the Hurd? Yes, only root gets access to privileged ports. > But it makes sense. Now I know why currently only root can run > subhurd. Indeed. A subhurd currently is just a second complete Hurd instance, quite equal in almost all regards to the main instance. (Thus the name "neighbor Hurd" is actually more precise...) Only root can provide the necessary privileged ports when booting the subhurd. The solution is to make it possible for the subhurd to run without the privileged ports -- either by implementing proxies that behave just like the real privileged ports, except that their actions are limited by what the user running them has access to; or by implementing a special interface for vitualized devices, which the guest system can handle explicitely (para-virtualization). > How does the network supervisor work? Is it similar to the second > solution I have mentioned (every pfinet has to send packets to a > central process first which helps forward them)? Exactly. > And why is the network supervisor implemented easily than the BPF > translator for helping subhurd communicate with the main Hurd? I mean > since subhurd can communicate with the supervisor, why can it not > communicate with the BPF translator of the main Hurd in the same way? Well, for one -- as I said -- the hypervisor could be completely transparent, just emulating the "real" device, so the subhurd doesn't even know it's not talking to the kernel. This is more complicated on the hypervisor side, but has the advantage of requiring no modifications in the guest system using it. But I initially thought even in the para-virtualized case, where the system is modified to talk to a special device with an explicitely virtual interface rather than something looking like the kernel device, an indepentant hypervisor still could be easier than a normal translator, because it can offer an interface that is explicitely meant to be used by independant systems... However, thinking a bit more about it, I realize that this notion was probably wrong. What make translators tricky is the lookup and authentication stuff. But the subhurd will get a port ready for use (authenticated against the user running the subhurd). And once you have the actual port, a translator can implement any kind of interface it likes -- it could actually be the very same interface that a standalone hypervisor would have! So unless I am missing something important now, my previous statement was false. Having the hypervisor (or the BPF server) implemented as a translator should not make things more complicated in any way :-) -antrik-
