public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	Rui Sousa <rui.sousa@nxp.com>,
	Ferenc Fejes <ferenc.fejes@ericsson.com>
Subject: Re: [RFC PATCH net-next 1/7] net: ethtool: netlink: introduce ethnl_update_bool()
Date: Wed, 17 Aug 2022 11:52:57 +0000	[thread overview]
Message-ID: <20220817115256.4zzcj3bg3mrlwejk@skbuf> (raw)
In-Reply-To: <20220817112729.4aniwysblnarakwx@lion.mk-sys.cz>

On Wed, Aug 17, 2022 at 01:27:29PM +0200, Michal Kubecek wrote:
> On Wed, Aug 17, 2022 at 01:29:14AM +0300, Vladimir Oltean wrote:
> > For a reason I can't really understand, ethnl_update_bool32() exists,
> > but the plain function that operates on a boolean value kept in an
> > actual u8 netlink attribute doesn't.
> 
> I can explain that: at the moment these helpers were introduced, only
> members of traditional structures shared with ioctl interface were
> updated and all attributes which were booleans logically were
> represented as u32 in them so that no other helper was needed back then.

Thanks, but the internal data structures of the kernel did not
necessitate boolean netlink attributes to be promoted to u32 just
because the ioctl interface did it that way; or did they?

Or otherwise said, is there a technical requirement that if a boolean is
passed to the kernel as u32 via ioctl, it should be passed as u32 via
netlink too?

  reply	other threads:[~2022-08-17 11:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 22:29 [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 1/7] net: ethtool: netlink: introduce ethnl_update_bool() Vladimir Oltean
2022-08-17 11:27   ` Michal Kubecek
2022-08-17 11:52     ` Vladimir Oltean [this message]
2022-08-17 12:00       ` Vladimir Oltean
2022-08-17 12:05         ` Michal Kubecek
2022-08-16 22:29 ` [RFC PATCH net-next 2/7] net: ethtool: add support for Frame Preemption and MAC Merge layer Vladimir Oltean
2022-08-17  3:22   ` Jakub Kicinski
2022-08-17 11:41     ` Vladimir Oltean
2022-08-17 18:35       ` Jakub Kicinski
2022-08-17 23:15   ` Vinicius Costa Gomes
2022-08-19 16:12     ` Vladimir Oltean
2022-08-24  0:35       ` Vinicius Costa Gomes
2022-09-07 20:57         ` Vladimir Oltean
2022-09-10  0:19           ` Vinicius Costa Gomes
2022-09-10 16:36             ` Vladimir Oltean
2022-09-14  2:59               ` Vinicius Costa Gomes
2022-09-15 14:14                 ` Vladimir Oltean
2022-11-10 10:33                   ` 回复: " Xiaoliang Yang
2022-11-14 15:42                     ` Vladimir Oltean
2022-11-15  3:01                       ` 回复: " Xiaoliang Yang
2022-11-16 12:36                         ` Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 3/7] net: ethtool: stats: make stats_put_stats() take input from multiple sources Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 4/7] net: ethtool: stats: replicate standardized counters for the pMAC Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 5/7] net: enetc: parameterize port MAC stats to also cover " Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 6/7] net: enetc: expose some standardized ethtool counters Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 7/7] net: enetc: add support for Frame Preemption and MAC Merge layer Vladimir Oltean
2022-08-17  3:34 ` [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool Jakub Kicinski
2022-08-17 11:50   ` Vladimir Oltean
2022-08-17 18:46     ` Jakub Kicinski
2022-10-01 15:53       ` Vladimir Oltean
2022-10-03 14:36         ` Jakub Kicinski
2022-10-03 14:51           ` Vladimir Oltean
2022-08-17 22:47 ` Vinicius Costa Gomes
2022-08-19  8:16 ` Kurt Kanzenbach
2022-08-19 16:59   ` Vladimir Oltean
2022-08-23 10:50     ` Kurt Kanzenbach

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=20220817115256.4zzcj3bg3mrlwejk@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ferenc.fejes@ericsson.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rui.sousa@nxp.com \
    --cc=vinicius.gomes@intel.com \
    --cc=xiaoliang.yang_1@nxp.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