Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages

["Daniel Walker (danielwa)" <danielwa@cisco.com>]

On Mon, Feb 17, 2020 at 06:52:35PM -0800, David Miller wrote:
> From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
> Date: Mon, 17 Feb 2020 17:52:11 +0000
> 
> > On Mon, Feb 17, 2020 at 08:44:35PM +0300, Evgeniy Polyakov wrote:
> >>    Hi Daniel, David
> >>     
> >>    17.02.2020, 20:26, "Daniel Walker (danielwa)" <danielwa@cisco.com>:
> >>    > On Sun, Feb 16, 2020 at 06:44:43PM -0800, David Miller wrote:
> >>    >>  This is a netlink based facility, therefore please you should add
> >>    filtering
> >>    >>  capabilities to the netlink configuration and communications path.
> >>    >>
> >>    >>  Module parameters are quite verboten.
> >>    >
> >>    > How about adding in Kconfig options to limit the types of messages? The
> >>    issue
> >>    > with this interface is that it's very easy for someone to enable the
> >>    interface
> >>    > as a listener, then never turn the interface off. Then it becomes a
> >>    broadcast
> >>    > interface. It's desirable to limit the more noisy messages in some
> >>    cases.
> >>     
> >>     
> >>    Compile-time options are binary switches which live forever after kernel
> >>    config has been created, its not gonna help those who enabled messages.
> >>    Kernel modules are kind of no-go, since it requires reboot to change in
> >>    some cases.
> >>     
> >>    Having netlink control from userspace is a nice option, and connector has
> >>    simple userspace->kernelspace channel,
> >>    but it requires additional userspace utils or programming, which is still
> >>    cumbersome.
> >>     
> >>    What about sysfs interface with one file per message type?
> > 
> > You mean similar to the module parameters I've done, but thru sysfs ? It would
> > work for Cisco. I kind of like Kconfig because it also reduces kernel size for
> > messages you may never want to see.
> 
> Even the sysfs has major downsides, as it fails to take the socket context into
> consideration and makes a system wide decision for what should be a per service
> decision.

It's multicast and essentially broadcast messages .. So everyone gets every
message, and once it's on it's likely it won't be turned off. Given that, It seems
appropriate that the system administrator has control of what messages if any
are sent, and it should effect all listening for messages.

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.

Daniel