From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754422AbbJPRiL (ORCPT ); Fri, 16 Oct 2015 13:38:11 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:33625 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753784AbbJPRhx (ORCPT ); Fri, 16 Oct 2015 13:37:53 -0400 Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs To: Daniel Borkmann , Hannes Frederic Sowa , davem@davemloft.net References: <1444991103.2861759.411876897.42C807BD@webmail.messagingengine.com> <5620FD52.2060103@iogearbox.net> <1445013408.2943971.412165665.3C995178@webmail.messagingengine.com> <5621337D.8090003@iogearbox.net> Cc: viro@ZenIV.linux.org.uk, ebiederm@xmission.com, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov From: Alexei Starovoitov Message-ID: <562135F0.5050401@plumgrid.com> Date: Fri, 16 Oct 2015 10:37:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5621337D.8090003@iogearbox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/15 10:27 AM, Daniel Borkmann wrote: >>> but don't know how flexible we are in >>> terms of adding S_IFBPF to the UAPI. >> >> I don't think it should be a problem. You referred to POSIX Standard in >> your other mail but I can't see any reason why not to establish a new >> file mode. Anyway, FreeBSD (e.g. whiteouts) and Solaris (e.g. Doors, >> Event Ports) are just examples of new modes being added. >> >> mknod /bpf/map/1 m 1 1 >> >> :) >> >> Yes, maybe I think this is a better solution architectural instead of >> constructing a new filesystem. > > Yeah, also 'man 2 stat' lists a couple of others used by various systems. > > The pro's of this approach would be that no new file system would be needed > and the special inode could be placed on top of any 'regular' file system > that would support special files. I do like that as well. I don't like it at all for the reasons you've just stated: 'it will prevent us doing shell style access to such files' > I'm wondering whether this would prevent us in future from opening access > to shell tools etc on that special file, but probably one could provide a > default set of file ops via init_special_inode() that could be overloaded > by the underlying fs if required. and also because adding new S_ISSOCK-like bit for bpf feel as a begining of nightmare, since sooner or later all filesystems would need to have a check for it like they have for sock type.