From: Bodo Eggert <7eggert@gmx.de>
Subject: Re: file as a directory
To: Martin Waitz <tali@admingilde.org>, Amit Gud <amitgud1@gmail.com>,
       linux-kernel@vger.kernel.org, reiserfs-list@namesys.com
Reply-To: 7eggert@nurfuerspam.de
Date: Fri, 26 Nov 2004 05:11:53 +0100
References: <fa.imi6gu8.1e7qkqc@ifi.uio.no> <fa.hcr9rb0.k6egam@ifi.uio.no>
User-Agent: KNode/0.7.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-Id: <E1CXXSb-0000bz-00@be1.7eggert.dyndns.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2526
Lines: 48

Martin Waitz wrote:
> On Mon, Nov 22, 2004 at 08:34:02AM -0700, Zan Lynx wrote:

>> There are already several things in filesystems that don't strictly
>> belong inside the kernel.  A filesystem could be implemented quite well
>> as a user-space daemon that sat on top of the block device and
>> communicated via sockets or shared memory just like an X server.
> 
> this is quite different.
> As you need to enforce security policies when accessing the block
> device, you have to move the filesystem into its own daemon.
> You cannot do it in a library.

Only the mapping from block-nr to uid/gid/perms needs to be in the kernel.
The rest can be done in userspace, but it would be ugly as hell.

> It is irrelevant for the application weather the fs resides in a
> separate daemon or in the kernel itself.

ACK.

> But support of different views on files is something different.
> You can do that in a library, you only need an interface that is
> capable of storing your data. The kernel already provides that
> interface.

If you want to allow users to set their default shell using some extension,
a simple userspace library will not do the job. You'll need a central
authority that is able to synchronize the access to the file, prevent
unauthorized modifications, do the caching etc.

I think the special file handlers should generally be daemons, but the
access should be controlled by kernel hooks, maybe something like
automounting a userspace filesystem. Simple meta-filesystems, e.g. those
that could be "emulated" using mount -oloop, may reside in the kernel
space, more complicated but common ones may be stored in the kernel
(placed on the initramfs?) to accelerate starting the helper daemon and
uncommon ones would be registered at runtime (maybe user-specific).

Having functions in the kernel to support those filesystems in the kernel
will help, e.g. a tgz helper daemon would need to allocate temporary
storage for accelerating access (e.g. file tree, cache) as well as means
to reassemble the tgz for operations on the whole file after write
operations occured. Meta-filesystems on fs without these features can
(off cause) be done, but I think they would be very slow or show
inconsitencies in certain situations.
-- 
Bug? That's not a bug, that's a feature. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/