From: David Miller <davem@davemloft.net>
To: danielwa@cisco.com
Cc: zbr@ioremap.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages
Date: Mon, 17 Feb 2020 18:52:35 -0800 (PST) [thread overview]
Message-ID: <20200217.185235.495219494110132658.davem@davemloft.net> (raw)
In-Reply-To: <20200217175209.GM24152@zorba>
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.
next prev parent reply other threads:[~2020-02-18 2:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 19:29 [PATCH] drivers: connector: cn_proc: allow limiting certain messages Daniel Walker
2020-02-17 2:44 ` David Miller
2020-02-17 17:25 ` Daniel Walker (danielwa)
[not found] ` <16818701581961475@iva7-8a22bc446c12.qloud-c.yandex.net>
2020-02-17 17:52 ` Daniel Walker (danielwa)
2020-02-17 18:32 ` Evgeniy Polyakov
2020-02-18 2:52 ` David Miller [this message]
2020-02-18 16:30 ` Daniel Walker (danielwa)
2020-02-18 16:46 ` Evgeniy Polyakov
2020-02-18 16:55 ` Daniel Walker (danielwa)
2020-02-18 20:35 ` David Miller
2020-02-18 20:54 ` Daniel Walker (danielwa)
2020-02-19 1:19 ` Evgeniy Polyakov
2020-02-19 15:37 ` Daniel Walker (danielwa)
2020-02-18 2:50 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200217.185235.495219494110132658.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=danielwa@cisco.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).