Messages in this thread | ![/](/images/icornerl.gif) | | From | "Daniel Walker (danielwa)" <> | Subject | Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages | Date | Wed, 19 Feb 2020 15:37:18 +0000 |
| |
On Wed, Feb 19, 2020 at 04:19:36AM +0300, Evgeniy Polyakov wrote: > 18.02.2020, 23:55, "Daniel Walker (danielwa)" <danielwa@cisco.com>: > >> > I think I would agree with you if this was unicast, and each listener could tailor > >> > what messages they want to get. However, this interface isn't that, and it would > >> > be considerable work to convert to that. > >> > >> You filter at recvmsg() on the specific socket, multicast or not, I > >> don't understand what the issue is. > > > > Cisco tried something like this (I don't know if it was exactly what your referring to), > > and it was messy and fairly complicated for a simple interface. In fact it was > > the first thing I suggested for Cisco. > > > > I'm not sure why Connector has to supply an exact set of messages, one could > > just make a whole new kernel module hooked into netlink sending a different > > subset of connector messages. The interface eats up CPU and slows the > > system if it's sending messages your just going to ignore. I'm sure the > > filtering would also slows down the system. > > Connector has unicast interface and multicast-like 'subscription', but sending system-wide messages > implies using broadcast interface, since you can not hold per-user/per-socket information about particular > event mask, instead you have channels in connector each one could have been used for specific message type, > but it looks overkill for simple process mask changes. > > And in fact, now I do not understand your point. > I thought you have been concerned about receiving too many messages from particular connector module because > there are, for example, too many 'fork/signal' events. And now you want to limit them to 'fork' events only. > Even if there could be other users who wanted to receive 'signal' and other events.
This is what I'm looking for, except not fork.
> And you blame connector - basically a network media, call it TCP if you like - for not filtering this for you? > And after you have been told to use connector channels - let's call them TCP ports - > which requires quite a bit of work - you do not want to do this (also, this will break backward compatibility for everyone > else including (!) Cisco (!!)). I'm a little bit lost here.
Maybe I'm confusing connector with cn_proc. Of course I've modified cn_proc, and that's all I'm concern with. If Connector is a larger entity for tranmission I'm not concerned with that.
To be honest, I'm not sure where you confusion is coming from. My original patch is what I want, and what i need, and what we're discussing. If David suggested something I didn't understand, then maybe we discussing something from two different perspectives.
> As a side and more practical way - do we want to have a global switch for particular process state changes broadcasting?
I think it would depend if it's likely to have multiple processes listening. Cisco would likely have one process, but there could be a case with containers tools where there multiple listeners. I don't know how the containers tools are using this interface.
Daniel
| ![\](/images/icornerr.gif) |