All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: mark diener <rpzrpzrpz@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: RFC: nft.8 review
Date: Tue, 20 Dec 2016 18:21:30 +0100	[thread overview]
Message-ID: <20161220172130.GI13857@orbyte.nwl.cc> (raw)
In-Reply-To: <CAChgv6pVKFz3fH5yGCA+8av84=c_2Ob25hy5AcTL=YLzw+n7Aw@mail.gmail.com>

Hi Mark,

On Tue, Dec 20, 2016 at 10:27:45AM -0600, mark diener wrote:
> Will the V8 NFT have byte level protocol compatibility with current
> linux kernel versions?

We were talking about nft manpage (which happens to live in section 8,
hence why I referred to it as 'nft.8'), not some version 8 (which would
still take a while to come as we're only at version 0.6 ATM).

> I am deployed on kernel  4.4.0-53-generic and would like to know when
> structural defines like RTM_NEWADDR,NLM_F_REQUEST, etc become updated
> or obsoleted.

Not sure I understand you correctly, but why should userspace exported
constants like RTM_NEWADDR or NLM_F_REQUEST become obsolete? This would
break backwards compatibility, which is generally frowned upon.

> As you can likely tell, I am not using libmnl or libnft but using
> direct NETFILTER kernel calls.
> 
> What a challenge to scan the code and reverse-engineer the byte
> sequences and understand the way the NFT virtual machine works in the
> kernel.

Sounds like you're baking your own cake here. I'd say if you decide to
reinvent the wheel, well, then you have to invent a wheel. No? ;)

Cheers, Phil

  reply	other threads:[~2016-12-20 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-10 10:27 RFC: nft.8 review Phil Sutter
2016-12-19 23:53 ` Pablo Neira Ayuso
2016-12-20 16:27   ` mark diener
2016-12-20 17:21     ` Phil Sutter [this message]
2016-12-20 17:42       ` mark diener

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=20161220172130.GI13857@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rpzrpzrpz@gmail.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.