lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <E1HpXOa-0003CR-00@calista.eckenfels.net>
Date:	Sun, 20 May 2007 00:27:28 +0200
From:	Bernd Eckenfels <ecki@...a.inka.de>
To:	linux-kernel@...r.kernel.org
Subject: Re: VFS design question

In article <1179611516.6558.357.camel@...ntown> you wrote:
> I tried to make it clear that I am clearly lacking expertise in this
> topic. I am currently working on a somewhat related topic and was hoping
> to get some reactions that would point me in the right directions as it
> is somewhat hard to judge the VFS design when you do not have prior
> experience in writing a file system on your own. Nowhere did I ask for a
> 10 paged review on the matter.

VFS abstraction is not too limiting, because the interface to user space is
fixed by posix or other standards in the libc. So als long as the new
filesystem want to support that semantic, it is not really limited.

There are some cases which are a bit hard, for example inode numbers -
especially when you want to provice NFS support, but that is not
specifically a VFS Problem.

And: VFS has evolved over time, that is the advantage of open source, you
can just include new functions in the old filesystems when you think you
need to impriove the framework.

That said, if you look at Reiser4 for example, there are some plug-in
extensions which are not yet possible in VFS, since it is a more high level
interface...

There are some different file close/lock semantics out there, and VFS does
not even try to abstract them.

gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ