Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-PHdr: =?us-ascii?q?9a23=3Afx2R4hdYJG58Xu26BLBd1p7/lGMj4e+mNxMJ6p?=
 =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?=
 =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YyU8HclGS1ZN9HCgOk8TE8H7NBXf?=
From:   "Daniel Walker (danielwa)" <danielwa@cisco.com>
To:     David Miller <davem@davemloft.net>
CC:     "zbr@ioremap.net" <zbr@ioremap.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
Thread-Topic: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages
Thread-Index: AQHV5ni/yHZMW2wqgkeUEsFC+E+QMQ==
Date:   Tue, 18 Feb 2020 16:30:36 +0000
Message-ID: <20200218163030.GR24152@zorba>
References: <20200217172551.GL24152@zorba>
 <16818701581961475@iva7-8a22bc446c12.qloud-c.yandex.net>
 <20200217175209.GM24152@zorba>
 <20200217.185235.495219494110132658.davem@davemloft.net>
In-Reply-To: <20200217.185235.495219494110132658.davem@davemloft.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cisco.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6C431B50AFEE5842BBEB448953213781@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 78b4ab45-e630-483f-bfcf-08d7b48fe227
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 16:30:36.2164
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: br9JaVMmKyFIxx8kc9LCH+6KC2MWweGGQA/pGZkE8ZQwW5F2NwYIyxwW80uRbylsNihQkkCPJXwLC6Pkl98AeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2933
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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
>=20
> > On Mon, Feb 17, 2020 at 08:44:35PM +0300, Evgeniy Polyakov wrote:
> >>    Hi Daniel, David
> >>    =20
> >>    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 a=
dd
> >>    filtering
> >>    >>  capabilities to the netlink configuration and communications pa=
th.
> >>    >>
> >>    >>  Module parameters are quite verboten.
> >>    >
> >>    > How about adding in Kconfig options to limit the types of message=
s? 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 som=
e
> >>    cases.
> >>    =20
> >>    =20
> >>    Compile-time options are binary switches which live forever after k=
ernel
> >>    config has been created, its not gonna help those who enabled messa=
ges.
> >>    Kernel modules are kind of no-go, since it requires reboot to chang=
e in
> >>    some cases.
> >>    =20
> >>    Having netlink control from userspace is a nice option, and connect=
or has
> >>    simple userspace->kernelspace channel,
> >>    but it requires additional userspace utils or programming, which is=
 still
> >>    cumbersome.
> >>    =20
> >>    What about sysfs interface with one file per message type?
> >=20
> > You mean similar to the module parameters I've done, but thru sysfs ? I=
t would
> > work for Cisco. I kind of like Kconfig because it also reduces kernel s=
ize for
> > messages you may never want to see.
>=20
> Even the sysfs has major downsides, as it fails to take the socket contex=
t into
> consideration and makes a system wide decision for what should be a per s=
ervice
> 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, I=
t seems
appropriate that the system administrator has control of what messages if a=
ny
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=