All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Cole <cole@opteqint.net>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Variant symlink filesystem
Date: Fri, 11 Mar 2016 21:18:07 +0100	[thread overview]
Message-ID: <56E327FF.1010103@nod.at> (raw)
In-Reply-To: <CACsf_ww2h6enKxSz5fCvwmipsyfBnwZeY78Vze8KHh8f-gUYjQ@mail.gmail.com>

Am 11.03.2016 um 21:15 schrieb Cole:
> On 11 March 2016 at 22:04, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>> On Fri, Mar 11, 2016 at 5:20 PM, Cole <cole@opteqint.net> 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.

Thanks,
//richard

  reply	other threads:[~2016-03-11 20:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 16:20 Variant symlink filesystem Cole
2016-03-11 16:44 ` Austin S. Hemmelgarn
2016-03-11 20:04 ` Richard Weinberger
2016-03-11 20:15   ` Cole
2016-03-11 20:18     ` Richard Weinberger [this message]
2016-03-11 20:22       ` Cole
2016-03-11 20:24         ` Richard Weinberger
2016-03-11 20:32           ` Cole
2016-03-11 20:36             ` Richard Weinberger
2016-03-11 22:27             ` David Lang
2016-03-11 20:38           ` Austin S. Hemmelgarn
2016-03-11 20:52             ` Cole
2016-03-11 21:51               ` Al Viro
2016-03-11 22:03                 ` Cole
2016-03-11 22:24                   ` Al Viro
2016-03-11 22:31                     ` Cole
2016-03-11 22:48                       ` David Lang
2016-03-11 22:54                         ` Cole
2016-03-11 22:38                   ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E327FF.1010103@nod.at \
    --to=richard@nod.at \
    --cc=cole@opteqint.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.