Hi, On Thu, Apr 10, 2008 at 02:14:06PM +0200, zhengda wrote:
> What I mean is the mechanism provided by the packet filter provides us > a possible solution. I don't expect it works now:-) I see :-) > As I can see, ether_filter in pfinet is hard coded. I think it's > better to allow the user to set up the filter according to their own > requirement. The communication between two pfinet may work by changing > ether_filter. Not really. The filter is only responsible for making sure that pfinet gets packets destined for the IP it handles. I don't see any reason why a user would want to change it -- it's intimately bound to the functionality of pfinet, and probably doesn't make sense to change without changing other parts of pfinet as well... > By the way, gnumach provides BPF and MPF. But pfinet seems to use MPF? > but why is BPF also provided? MPF is the original Mach Solution; BPF was added later AFAIK. IIRC Richard Braun (syn), who was working on the packet filter improvements, said that BPF is more common and more powerful... But that reminds me that filtering outgoing packages only works with BPF IIRC. So we would have to swith pfinet to use BPF for that... Part of the original plan was to create a BPF translator, so pfinet (and other potential users) would talk to this translator, rather than directly to the kernel. However, that work was never completed :-( Ideally, the BPF translator should be finished, and pfinet ported to that... > And why do you not think it's an elegant solution? Well, I generally dislike the idea of the packet filter in the kernel... On one Hand, it is convenient that you can run multiple systems in parallel (e.g. subhurds), and they don't need to know about each other at all; the only thing they have in common is the kernel. On the other hand, it doesn't really fit the microkernel philosophy: The functionality is limited and not modifiable without hacking the kernel... One consequence is that there is no policy what kind of filters a process can set -- any process that has the necessary permissions to access the device, can do anything it desires. When talking about the limitations of subhurds, I think I mentioned that device sharing is possible for hard disks and network interfaces, but the sharing is not safe -- now you know why. Fixing this would be part of the "improve subhurds" task, and it would involve writing a network server that acts as superviser, enforcing access policies for the subhurd. It would complicate subhurd startup a bit, but would make subhurds more useful... The BPF translator would be kind of a middle ground: It would leave tha actual packet filter in the kernel, but move the access to it outside. (And thus allow enforcing policies.) However, in a simple setup, only multiple servers running in a single Hurd instance would share the translator; other instances (subhurds) would still have their own server, and thus no policy would be enforced. It would be possible to force the subhurd to use the main Hurd's BPF translator. However, that would require some mechanism to allow a subhurd to access another Hurd's translators -- this could also be part of the "improve subhurds" task. It's much more complicated though than implementing a low-level server (supervisor), which could use a simpler interface, or even be completely transparent to the clients... (Pretending that it's the actual kernel device.) So you see, there are many options :-) -antrik-
