From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757790AbbJVNXE (ORCPT ); Thu, 22 Oct 2015 09:23:04 -0400 Received: from www62.your-server.de ([213.133.104.62]:35687 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753832AbbJVNXB (ORCPT ); Thu, 22 Oct 2015 09:23:01 -0400 Message-ID: <5628E323.1010808@iogearbox.net> Date: Thu, 22 Oct 2015 15:22:43 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexei Starovoitov , Thomas Graf CC: "Eric W. Biederman" , Hannes Frederic Sowa , davem@davemloft.net, viro@ZenIV.linux.org.uk, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs References: <1445280385.602530.414418777.63627F89@webmail.messagingengine.com> <562545AA.2080207@plumgrid.com> <1445284997.621186.414538017.6E35B341@webmail.messagingengine.com> <56255714.2070800@plumgrid.com> <56256BF9.1090500@iogearbox.net> <56258B11.9080505@plumgrid.com> <5625FF71.8020304@iogearbox.net> <56267FAF.60206@plumgrid.com> <87io61fjx3.fsf@x220.int.ebiederm.org> <5627AC79.5000704@iogearbox.net> <20151021183447.GC23554@pox.localdomain> <56281555.3030504@plumgrid.com> In-Reply-To: <56281555.3030504@plumgrid.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/22/2015 12:44 AM, Alexei Starovoitov wrote: ... > all users) When you have to hack drivers/base/core.c to get there it > should have been a warning sign that something is wrong with > this cdev approach. Hmm, you know, this had nothing to do with it, merely to save ~20 LoC that I can do just as well inside BPF framework. No changes in driver API needed. >> I've read the discussion passively and my take away is that, frankly, >> I think the differences are somewhat minor. Both architectures can >> scale to what we need. Both will do the job. I'm slightly worried about >> exposing uAPI as a FS, I think that didn't work too well for sysfs. It's >> pretty much a define the format once and never touch it again kind of >> deal. > > It's even worse in cdev style since it piggy backs on sysfs. I don't mind with what approach we're going in the end, but this kind of discussion is really tiring, and not going anywhere. Lets just make a beer call, so we can hash out a way forward that works for everyone. On that note: cheers! ;) Daniel