[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140314.160851.1134730495663127657.davem@davemloft.net>
Date: Fri, 14 Mar 2014 16:08:51 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ast@...mgrid.com
Cc: pablo@...filter.org, dborkman@...hat.com, mingo@...nel.org,
wad@...omium.org, rostedt@...dmis.org, a.p.zijlstra@...llo.nl,
hpa@...or.com, hagen@...u.net, jesse@...ira.com,
tglx@...utronix.de, edumazet@...gle.com,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
fweisbec@...il.com, acme@...radead.org, penberg@....fi,
arjan@...radead.org, hch@...radead.org, xemul@...allels.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v10 net-next 1/3] filter: add Extended BPF interpreter
and converter
From: Alexei Starovoitov <ast@...mgrid.com>
Date: Fri, 14 Mar 2014 12:51:17 -0700
> can you please explain why the status of these
> patches is 'deferred' in patchwork ?
> Is it because of bpf vs nft thread?
> I think that's orthogonal.
I do not find it orthogonal, Pablo brings up some very valid points
which I agree with.
EBPF has a lot of the same user side interface limitations that the
existing BPF has, and you refuse to accept this core point Pablo is
making.
That is, that it lacks extensibility, and is too strongly tied to the
implementation.
This is exactly how we run into problems in the future, and you'll be
proposing EBPF_2.0 to address such problems.
I refuse to setup such a situation, and there is absolutely not rush
whatsoever to apply your patches. We can take our time with this
stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists