> Um, no, they go through the kernel for that model as well, same > interface, it just depends on the type of message that you are sending > as to who the recipients are (single or more than one.)
In other words its bog standard classic network layer multicasting. You don't need much policy for that > How would packet filtering work here for this type of decision making? > That's a much more complex interface than what we have implemented, > don't you agree? No - its about 10 lines of code to invoke EBPF. The socket layer supports it today. What it doesn't have is the multicast transport bits. It's a classic networking layer item. I know DaveM didn't like the original because all the policy was mixed up in it and the blocking problem was undefined but every time I look at this I reach the same conclusion - Its a socket layer problem - The sk_buff structures are the memory allocator needed - The socket layer does the resource management - The socket layer has SCM_RIGHTS already - The socket layer has EBPF already - The socket layer has a fantastic debugging environment - It's the same components needed for fast MQ services and (almost) for HPC uses [HPC wants scatter/gather too] It just needs - RDP multicast AF_UNIX type sockets. Not in itself a huge problem, although it does need some nice refcounting so that you queue each message once and the readers share it. - A clear fairly policy-free description of how you deal with multicast to some clients who are "full" And I think that aspect of things needs to go back via the networking maintainers to figure out if this is "DaveM doesn't like dbus" or there are some actually insoluble problems I'm missing here. Designing alternate turds to go around DaveM may not be the right approach even if he's stubborn 8) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
