All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, nicolas.dichtel@6wind.com, fw@strlen.de,
	pablo@netfilter.org, jiri@resnulli.us, mkubecek@suse.cz,
	aleksander.lobakin@intel.com, Thomas Haller <thaller@redhat.com>
Subject: Re: [RFC] netlink: add variable-length / auto integers
Date: Wed, 11 Oct 2023 09:08:59 -0700	[thread overview]
Message-ID: <20231011090859.3fc30812@kernel.org> (raw)
In-Reply-To: <f75851720c356fe43771a5c452d113ca25d43f0f.camel@sipsolutions.net>

On Wed, 11 Oct 2023 15:11:15 +0200 Johannes Berg wrote:
> > +++ b/include/uapi/linux/netlink.h
> > @@ -298,6 +298,8 @@ struct nla_bitfield32 {
> >   *	entry has attributes again, the policy for those inner ones
> >   *	and the corresponding maxtype may be specified.
> >   * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
> > + * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
> > + * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B  
> 
> This is only for exposing the policy (policy description), not sure the
> alignment thing matters here?
> 
> OTOH, there's nothing in this file that ever describes *any* of the
> attributes, yet in pracice all the uapi headers do refer to NLA_U8 and
> similar - so we should probably have a new comment section here in the
> UAPI that describes the various types as used by the documentation of
> other families?
> 
> Anyway, I think some kind of bigger "careful with alignment" here would
> be good, so people do the correct thing and not just "if (big)
> nla_get_u64()" which would get the alignment thing problematic again.

I was planning to add the docs to Documentation/userspace-api/netlink/
Is that too YNL-specific?

diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst
index cc4e2430997e..a8218284e67a 100644
--- a/Documentation/userspace-api/netlink/specs.rst
+++ b/Documentation/userspace-api/netlink/specs.rst
@@ -408,10 +408,21 @@ This section describes the attribute types supported by the ``genetlink``
 compatibility level. Refer to documentation of different levels for additional
 attribute types.
 
-Scalar integer types
+Common integer types
 --------------------
 
-Fixed-width integer types:
+``sint`` and ``uint`` represent signed and unsigned 64 bit integers.
+If the value can fit on 32 bits only 32 bits are carried in netlink
+messages, otherwise full 64 bits are carried. Note that the payload
+is only aligned to 4B, so the full 64 bit value may be unaligned!
+
+Common integer types should be preferred over fix-width types in majority
+of cases.
+
+Fix-width integer types
+-----------------------
+
+Fixed-width integer types include:
 ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, ``s16``, ``s32``, ``s64``.
 
 Note that types smaller than 32 bit should be avoided as using them
@@ -421,6 +432,9 @@ See :ref:`pad_type` for padding of 64 bit attributes.
 The payload of the attribute is the integer in host order unless ``byte-order``
 specifies otherwise.
 
+64 bit values are usually aligned by the kernel but it is recommended
+that the user space is able to deal with unaligned values.
+
 .. _pad_type:
 
 pad

  parent reply	other threads:[~2023-10-11 16:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
2023-10-11  3:20 ` kernel test robot
2023-10-11 13:11 ` Johannes Berg
2023-10-11 14:03   ` Nicolas Dichtel
2023-10-11 15:52     ` Jakub Kicinski
2023-10-11 16:01       ` Johannes Berg
2023-10-11 16:45         ` Stephen Hemminger
2023-10-12  9:26           ` David Laight
2023-10-12  6:47       ` Nicolas Dichtel
2023-10-11 16:08   ` Jakub Kicinski [this message]
2023-10-11 16:16     ` Johannes Berg
2023-10-11 16:19       ` Jakub Kicinski
2023-10-11 13:46 ` Jiri Pirko
2023-10-11 16:16   ` Jakub Kicinski
2023-10-11 16:21     ` Johannes Berg
2023-10-11 16:34       ` Jakub Kicinski
2023-10-11 16:37         ` Johannes Berg
2023-10-11 17:01     ` Jiri Pirko
2023-10-11 20:21       ` Jakub Kicinski
2023-10-12 12:36 ` kernel test robot
2023-10-14 12:35 ` kernel test robot

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=20231011090859.3fc30812@kernel.org \
    --to=kuba@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=fw@strlen.de \
    --cc=jiri@resnulli.us \
    --cc=johannes@sipsolutions.net \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=pablo@netfilter.org \
    --cc=thaller@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.