[RFC PATCH] add filesystem subtype support

2007-02-12 Thread Miklos Szeredi
There's a slight problem with filesystem type representation in fuse based filesystems. From the kernel's view, there are just two filesystem types: fuse and fuseblk. From the user's view there are lots of different filesystem types. The user is not even much concerned if the filesystem is fuse

[PATCH 1/1][RFC] EXT34 retry loop issue V(2)

2007-02-12 Thread Dmitriy Monakhov
Patch depends on : [PATCH 0/1][RFC] prepare_write positive return value V(2) This patch solve ext3/4 retry loop issue. Issue description: What we can do if block_prepare_write fail inside ext3_prepare_write ? a) Stop transaction and do retry if possible, but what happend if reboot comes

Re: [RFC PATCH] add filesystem subtype support

2007-02-12 Thread Szakacsits Szabolcs
Hi, On Mon, 12 Feb 2007, Miklos Szeredi wrote: There's a slight problem with filesystem type representation in fuse based filesystems. From the kernel's view, there are just two filesystem types: fuse and fuseblk. From the user's view there are lots of different filesystem types. The

Re: [RFC PATCH] add filesystem subtype support

2007-02-12 Thread Miklos Szeredi
There's a slight problem with filesystem type representation in fuse based filesystems. From the kernel's view, there are just two filesystem types: fuse and fuseblk. From the user's view there are lots of different filesystem types. The user is not even much concerned if the

Re: [RFC PATCH] add filesystem subtype support

2007-02-12 Thread Jan Engelhardt
Hi, On Feb 12 2007 12:50, Miklos Szeredi wrote: Index: linux/fs/filesystems.c === --- linux.orig/fs/filesystems.c2007-02-12 12:42:55.0 +0100 +++ linux/fs/filesystems.c 2007-02-12 12:43:00.0 +0100 @@ -42,11

[GIT PULL -mm] Unionfs updates/cleanups

2007-02-12 Thread Josef 'Jeff' Sipek
The following patches (also available though the git tree) fix few cleanliness issues with Unionfs. You can pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git to receive the following: Erez Zadok (1): Unionfs: Documentation update Josef 'Jeff'

[PATCH 3/3] Unionfs: Documentation update

2007-02-12 Thread Josef 'Jeff' Sipek
From: Erez Zadok [EMAIL PROTECTED] Be little gentler updated the URLs Signed-off-by: Erez Zadok [EMAIL PROTECTED] Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED] --- Documentation/filesystems/unionfs/00-INDEX |8 -- Documentation/filesystems/unionfs/issues.txt | 23

[PATCH 1/3] fs/unionfs/: Use __roundup_pow_of_two instead of custom rounding code

2007-02-12 Thread Josef 'Jeff' Sipek
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED] --- fs/unionfs/rdstate.c | 11 ++- fs/unionfs/union.h |1 + 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/unionfs/rdstate.c b/fs/unionfs/rdstate.c index 16ce1bf..e240285 100644 --- a/fs/unionfs/rdstate.c +++

[PATCH 2/3] fs/: Move eCryptfs Unionfs config options into a sub-menu

2007-02-12 Thread Josef 'Jeff' Sipek
Using The Misc filesystems sub-menu for layered/stackable filesystems only makes it harder for users to find eCryptfs/Unionfs. Additionally, the menu can be easily turned into a menuconfig, which could be used to turn on any VFS/VM functionality required by layered filesystems (there is none at

Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

2007-02-12 Thread J. Bruce Fields
On Tue, Feb 06, 2007 at 10:37:37AM +, Christoph Hellwig wrote: On Tue, Feb 06, 2007 at 09:26:14PM +1100, Neil Brown wrote: What would be the benefit of having private non-visible vfsmounts? Sounds like a recipe for confusion? It is possible that mountd might start doing bind-mounts

Re: [RFC PATCH] add filesystem subtype support

2007-02-12 Thread Miklos Szeredi
-static struct file_system_type **find_filesystem(const char *name) +static struct file_system_type **find_filesystem(const char *name, unsigned len) { struct file_system_type **p; for (p=file_systems; *p; p=(*p)-next) -if (strcmp((*p)-name,name) == 0) +

Re: [take35 0/10] kevent: Generic event handling mechanism.

2007-02-12 Thread Evgeniy Polyakov
On Mon, Feb 05, 2007 at 05:23:36PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Feb 01, 2007 at 01:12:30PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: Generic event handling mechanism. Kevent is a generic subsytem which allows to handle event notifications. It

[take36 1/10] kevent: Description.

2007-02-12 Thread Evgeniy Polyakov
Description. diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt new file mode 100644 index 000..d6e126f --- /dev/null +++ b/Documentation/kevent.txt @@ -0,0 +1,271 @@ +Description. + +int kevent_init(struct kevent_ring *ring, unsigned int ring_size, + unsigned int

[take36 10/10] kevent: Kevent based generic AIO.

2007-02-12 Thread Evgeniy Polyakov
Kevent based generic AIO. This patch only implements network AIO, which is _COMPLETELY_ impossible and broken in _ANY_ micro-thread design. For details and test consider following link: http://tservice.net.ru/~s0mbre/blog/2007/02/10#2007_02_10 Designing AIO without network in mind can only be

Re: [take36 10/10] kevent: Kevent based generic AIO.

2007-02-12 Thread Andi Kleen
Evgeniy Polyakov [EMAIL PROTECTED] writes: aio_sendfile_path() is essentially aio_sendfile(), except that it takes source filename as parameter, has a pointer to private header and its size (which allows to send header and file's content in one syscall instead of three (open, send, sendfile)

Re: [take36 10/10] kevent: Kevent based generic AIO.

2007-02-12 Thread Evgeniy Polyakov
On Mon, Feb 12, 2007 at 02:08:10PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov [EMAIL PROTECTED] writes: aio_sendfile_path() is essentially aio_sendfile(), except that it takes source filename as parameter, has a pointer to private header and its size (which allows to

Re: [take36 10/10] kevent: Kevent based generic AIO.

2007-02-12 Thread Alan
I'm sure others would want them then for their favourite system call combo too. If they were really useful it might make more sense to have a batch() system call that works for arbitary calls, but I'm not convinced yet it's even needed. It would be certainly ugly. batch() would possibly make

Re: [take36 10/10] kevent: Kevent based generic AIO.

2007-02-12 Thread Evgeniy Polyakov
On Mon, Feb 12, 2007 at 01:12:57PM +, Alan ([EMAIL PROTECTED]) wrote: I'm sure others would want them then for their favourite system call combo too. If they were really useful it might make more sense to have a batch() system call that works for arbitary calls, but I'm not convinced

Re: [take35 0/10] kevent: Generic event handling mechanism.

2007-02-12 Thread Ulrich Drepper
Evgeniy Polyakov wrote: I think that mean that everybody is happy with APi, design and set of features. No comment means that I still have not been able to test anything since regardless of what version I tried, it failed to build. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧

Re: [take35 0/10] kevent: Generic event handling mechanism.

2007-02-12 Thread Andrew Morton
On Mon, 12 Feb 2007 13:35:10 +0300 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Andrew, do you consider kevent for inclusion or declining? I haven't had time to think about it in the past month or two, sorry. However we might as well get it back in there for review-and-test - please send a new

Re: [take35 0/10] kevent: Generic event handling mechanism.

2007-02-12 Thread Evgeniy Polyakov
On Mon, Feb 12, 2007 at 06:59:17AM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: I think that mean that everybody is happy with APi, design and set of features. No comment means that I still have not been able to test anything since regardless of what version

Re: [take35 0/10] kevent: Generic event handling mechanism.

2007-02-12 Thread Evgeniy Polyakov
On Mon, Feb 12, 2007 at 09:13:35AM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: On Mon, 12 Feb 2007 13:35:10 +0300 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Andrew, do you consider kevent for inclusion or declining? I haven't had time to think about it in the past month or two,