Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752177AbcCKUWR (ORCPT ); Fri, 11 Mar 2016 15:22:17 -0500 Received: from mail-vk0-f54.google.com ([209.85.213.54]:33511 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbcCKUWP (ORCPT ); Fri, 11 Mar 2016 15:22:15 -0500 MIME-Version: 1.0 X-Originating-IP: [196.210.30.63] In-Reply-To: <56E327FF.1010103@nod.at> References: <56E327FF.1010103@nod.at> Date: Fri, 11 Mar 2016 22:22:13 +0200 Message-ID: Subject: Re: Variant symlink filesystem From: Cole To: Richard Weinberger Cc: LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2017 Lines: 47 On 11 March 2016 at 22:18, Richard Weinberger wrote: > Am 11.03.2016 um 21:15 schrieb Cole: >> On 11 March 2016 at 22:04, Richard Weinberger >> wrote: >>> On Fri, Mar 11, 2016 at 5:20 PM, Cole wrote: >>>> Hi, >>>> >>>> I have written a Variant Symlink Filesystem for linux, currently >>>> implemented as a kernel module: >>>> https://github.com/onslauth/varsymfs >>>> The code was written for the 3.x kernel. >>>> >>>> I would like to try to get this included into the linux kernel, and am >>>> willing to hand over all copyright and change the license as needed. >>>> As such, I would like to know what I can do to try to make this >>>> happen. >>>> >>>> If the code quality or standards are not up to par with those of the >>>> linux kernel, or code needs to change due to newer changes introduced >>>> into the kernel, please let me know and I will endeavour to make the >>>> necessary changes. >>>> >>>> Please can you also cc me in any replies, as I am not currently >>>> subscribed to the list. >>> >>> Why does this need to be a kernel filesystem and not a filesystem in >>> userspace (FUSE)? >>> Especially as you are dealing with environment variables which are >>> owned and controlled >>> by userspace. >> >> The original implementation was in fuse, to prove the concept. However, >> because we are compiling, as well as running programs and reading/writing >> files inside of this path, the performance loss is too great. Therefore we >> moved to this solution. > > Before giving up and going to kernelspace you could try improving the root cause of the performance loss. :) > Maybe the kernel interface for finding the env variables can be speeded up. If I remember correctly, when we were testing the fuse version, we hard coded the path to see if that solved the problem, and the difference between the env lookup code and the hard coded path was almost the same, but substantially slower than the native file system. Regards /Cole