On 2020-03-11, at 18:17:52 +0100, Pablo Neira Ayuso wrote: > On Wed, Mar 11, 2020 at 02:35:35PM +0000, Jeremy Sowden wrote: > > On 2020-03-11, at 14:26:13 +0100, Pablo Neira Ayuso wrote: > > > Do you think it would be to keep back this one from the nf-next > > > tree until you evaluate an alternative way to extend nft_bitwise? > > > > > > commit 8d1f378a51fcf2f5e44e06ff726a91c885d248cc > > > Author: Jeremy Sowden <jeremy@xxxxxxxxxx> > > > Date: Mon Feb 24 12:49:31 2020 +0000 > > > > > > netfilter: bitwise: add support for passing mask and xor > > > values in registers. > > > > If we do move away from converting all boolean op's to: > > > > d = (s & m) ^ x > > > > then it seems unlikely that the new attributes will be used. > > I see. > > > For me, it depends whether you rebase nf-next. I'm guessing not. > > In that case, I probably wouldn't bother reverting the patch now, > > since it's not big or invasive, and it wouldn't much matter if it > > went into 5.6 and got removed in a later patch-set. > > OK. I'm considering to rebase given this patch is not yet into > net-next, unless anyone here is opposed to this in order to pass a > pull-request with no add-patch-then-revert. Fbm. > Regarding the new extension, we only have to be careful when updating > userspace, so only new code uses the new bitwise extension you make. > Old code will still use the old boolean approach: > > d = (s & m) ^ x > > So only the payload with non-constant right-hand side will be using > your new extension for nft_bitwise. The kernel should definitely continue to support the old way of doing things. > For libnftnl, I'm inclined to revert. Agreed. > Let me know, thanks. J.
Attachment:
signature.asc
Description: PGP signature
