From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754397AbbJPRVs (ORCPT ); Fri, 16 Oct 2015 13:21:48 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:49285 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753550AbbJPRVq (ORCPT ); Fri, 16 Oct 2015 13:21:46 -0400 Message-Id: <1445016105.1251655.412231129.6574D430@webmail.messagingengine.com> X-Sasl-Enc: b3wiHkVFXFLTqhkfkAQYIwAO+E3XTFoeJ58lVWTiWodO 1445016105 From: Hannes Frederic Sowa To: Daniel Borkmann , davem@davemloft.net Cc: ast@plumgrid.com, viro@ZenIV.linux.org.uk, ebiederm@xmission.com, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-25d3ec43 Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs Date: Fri, 16 Oct 2015 19:21:45 +0200 In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > This eventually leads us to this patch, which implements a minimal > eBPF file system. The idea is a bit similar, but to the point that > these inodes reside at one or multiple mount points. A directory > hierarchy can be tailored to a specific application use-case from the > various subsystem users and maps/progs pinned inside it. Two new eBPF > commands (BPF_PIN_FD, BPF_NEW_FD) have been added to the syscall in > order to create one or multiple special inodes from an existing file > descriptor that points to a map/program (we call it eBPF fd pinning), > or to create a new file descriptor from an existing special inode. > BPF_PIN_FD requires CAP_SYS_ADMIN capabilities, whereas BPF_NEW_FD > can also be done unpriviledged when having appropriate permissions > to the path. > Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can see other ebpf-fs entities? I think Daniel wanted to already use the mountpoint as some kind of hierarchy delimiter. I would have used directories for that and multiple mounts would then have resulted in the same content of the filesystem. IMHO this would remove some ambiguity but then the question arises how this is handled in a namespaced environment. Was there some specific reason to do so? Thanks, Hannes