From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Evgeniy Polyakov <zbr@ioremap.net>
Cc: David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages
Date: Mon, 17 Feb 2020 17:52:11 +0000 [thread overview]
Message-ID: <20200217175209.GM24152@zorba> (raw)
In-Reply-To: <16818701581961475@iva7-8a22bc446c12.qloud-c.yandex.net>
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.
Daniel
next prev parent reply other threads:[~2020-02-17 17: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) [this message]
2020-02-17 18:32 ` Evgeniy Polyakov
2020-02-18 2:52 ` David Miller
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=20200217175209.GM24152@zorba \
--to=danielwa@cisco.com \
--cc=davem@davemloft.net \
--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).