All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: RFD - Exposing netfilter types?
Date: Mon, 15 Dec 2025 22:43:46 +0100	[thread overview]
Message-ID: <aUCBAau7DREw8YmD@strlen.de> (raw)
In-Reply-To: <1944a019-39af-46e6-b489-96715dd2dd01@gmail.com>

Ian Pilcher <arequipeno@gmail.com> wrote:
> Recently, I asked what I thought would be a simple question.  How should
> an application go about determining the type of objects stored in an
> nftables set.
> 
>   https://marc.info/?l=netfilter&m=176546062431223&w=2
> 
> As seen in the response (thanks Florian!), doing this for all possible
> types, including concatenations, is actually pretty complicated.
> 
> Presumably, this is why the NFTA_SET_KEY_TYPE values that correspond to
> simple types aren't in any public header.  Instead, those values, along
> with all of the logic associated with complex types seem to exist solely
> within the nftables user-space utility (nft).

Yes.  Note that the type info is only used for formatting the data.
Its not used by the kernel and its not relevant for matching.

Theoretically nft could store that data on disk and not even
send it to the kernel.

> Of course, this presents a problem for any other application that wants
> to work with these types/values.  Today, any such program needs to copy
> the values and/or logic that it needs from the nft sources.

Yes.

> Is there any reason that the type-related stuff that's currently in nft
> shouldn't be broken out into a separate library that other applications
> could also use?

Whats the use case?

  reply	other threads:[~2025-12-15 21:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 20:13 RFD - Exposing netfilter types? Ian Pilcher
2025-12-15 21:43 ` Florian Westphal [this message]
2025-12-16 16:05   ` Ian Pilcher

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=aUCBAau7DREw8YmD@strlen.de \
    --to=fw@strlen.de \
    --cc=arequipeno@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    /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.