From: Lukasz Majewski <lukma@denx.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Eric Dumazet <edumazet@google.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Tristram.Ha@microchip.com,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Paolo Abeni <pabeni@redhat.com>,
Ravi Gunasekaran <r-gunasekaran@ti.com>,
Simon Horman <horms@kernel.org>,
Wojciech Drewek <wojciech.drewek@intel.com>,
Nikita Zhandarovich <n.zhandarovich@fintech.ru>,
Murali Karicheri <m-karicheri2@ti.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
Ziyang Xuan <william.xuanziyang@huawei.com>,
Kristian Overskeid <koverskeid@gmail.com>,
Matthieu Baerts <matttbe@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] net: hsr: Provide RedBox support
Date: Fri, 1 Mar 2024 10:37:05 +0100 [thread overview]
Message-ID: <20240301103705.2f308b83@wsk> (raw)
In-Reply-To: <399bf6c2-c9be-4f41-8df5-8d9655e34003@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]
Hi Andrew,
> On Thu, Feb 29, 2024 at 10:25:57AM +0100, Lukasz Majewski wrote:
> > Hi Andrew,
> >
> > > On Wed, Feb 28, 2024 at 08:31:15AM -0800, Stephen Hemminger
> > > wrote:
> > > > On Wed, 28 Feb 2024 16:07:35 +0100
> > > > Lukasz Majewski <lukma@denx.de> wrote:
> > > >
> > > > >
> > > > > +/* hsr_proxy_node_table_show - Formats and prints proxy
> > > > > node_table entries */ +static int
> > > > > +hsr_proxy_node_table_show(struct seq_file *sfp, void *data)
> > > > > +{
> > > > > + struct hsr_priv *priv = (struct hsr_priv
> > > > > *)sfp->private;
> > > > > + struct hsr_node *node;
> > > > > +
> > > > > + seq_printf(sfp, "Proxy Node Table entries for HSR
> > > > > device\n");
> > > > > + seq_puts(sfp, "MAC-Address-SAN, time_in\n");
> > > > > + rcu_read_lock();
> > > > > + list_for_each_entry_rcu(node, &priv->proxy_node_db,
> > > > > mac_list) {
> > > > > + seq_printf(sfp, "%pM ",
> > > > > &node->macaddress_A[0]);
> > > > > + seq_printf(sfp, "%10lx\n",
> > > > > node->time_in[HSR_PT_INTERLINK]);
> > > > > + }
> > > > > + rcu_read_unlock();
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > DEFINE_SHOW_ATTRIBUTE(hsr_node_table);
> > > > > +DEFINE_SHOW_ATTRIBUTE(hsr_proxy_node_table);
> > > >
> > > > NAK
> > > > Do not abuse sysfs to be a debug proc style output.
> > >
> > > This is actually debugfs, not sysfs.
> > >
> > > However, i agree, we want information like this exported via
> > > netlink as the primary interface to the end user. debugfs is not
> > > suitable for that.
> >
> > Am I correct, that recommended approach would be to:
> >
> > 1. Modify iproute2 to support for example:
> >
> > ip addr show dev hsr1 nodes {proxy} ?
>
> Something like that. iproute2 is more than the ip command. There is
> also bridge, dcb, vdpa, etc. So you need to decide where it fits best.
> Maybe as part of bridge? Or even a command of its own.
IMHO, 'bridge' is not the best place for hsr output, as 'NodeTable' can
(and should) be provided for non-redbox communication.
For now the ip looks like the best place.
>
> > 2. Shall the currently exported:
> >
> > /sys/kernel/debug/hsr/hsrX/node_table be left as it is (for legacy
> > usage) or shall it be removed and replaced with netlink and
> > iproute2 ?
>
> There is no legacy usage. debugfs is unstable, it is not KAPI. Nothing
> is expected to use it, because it could disappear at any time, its
> format can change, etc. For a long time, debugfs was not liked in
> networking, because it was abused and tools built on top of it, often
> vendor tools. We much prefer well defined interfaces such as
> netlink. But it seems like things are becoming a little bit more
> loose.
Ok. Thanks for the explanation.
> If you have a well defined netlink API making debugfs
> pointless, you can probably keep the debugfs code :-) But you can also
> remove it.
I would prefer to keep the code.
>
> Andrew
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-03-01 9:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 15:07 [RFC] net: hsr: Provide RedBox support Lukasz Majewski
2024-02-28 16:31 ` Stephen Hemminger
2024-02-28 17:03 ` Andrew Lunn
2024-02-29 9:25 ` Lukasz Majewski
2024-02-29 14:59 ` Andrew Lunn
2024-03-01 9:37 ` Lukasz Majewski [this message]
2024-02-28 17:13 ` Andrew Lunn
2024-02-29 9:30 ` Lukasz Majewski
2024-02-28 17:58 ` Dan Carpenter
2024-03-01 7:38 ` Ziyang Xuan (William)
2024-03-01 9:55 ` Lukasz Majewski
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=20240301103705.2f308b83@wsk \
--to=lukma@denx.de \
--cc=Tristram.Ha@microchip.com \
--cc=andrew@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=horms@kernel.org \
--cc=koverskeid@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=matttbe@kernel.org \
--cc=n.zhandarovich@fintech.ru \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=r-gunasekaran@ti.com \
--cc=stephen@networkplumber.org \
--cc=william.xuanziyang@huawei.com \
--cc=wojciech.drewek@intel.com \
/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).