Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> 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