[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29139.1245266909@redhat.com>
Date: Wed, 17 Jun 2009 20:28:29 +0100
From: David Howells <dhowells@...hat.com>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: dhowells@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andreas Dilger <adilger@....com>,
Alan Cox <alan@...rguk.ukuu.org.uk>, akpm@...ux-foundation.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-afs@...ts.infradead.org
Subject: Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s
Al Viro <viro@...IV.linux.org.uk> wrote:
> ... so we need a syscall that would do that "drop the caches" operation.
> _After_ having decided that it's really needed for symlinks.
If you want to support disconnected operation, then you need a way to (a) lock
an object in the cache, (b) unlock an object in the cache, (c) pull an object
into the cache, (d) kick an object out of the cache, (e) ban an object from the
cache, (f) reserve space in the cache for an object, (g) release the
reservation on an object and (h) find out the lock/ban/reservation status of an
object in the cache, and you'd need to support them for _all_ file types,
including dirs, symlinks, dev files and fifos. Probably not UNIX sockets,
though.
I can add a system call for each of these operations. I need some of them
anyway to implement kAFS if I'm not allowed pioctl().
<sarcasm> In fact, why don't I just make each AFS pioctl function a full-blown
syscall? That satisfies Linus's semantics requirement, and avoids the need for
a 'typeless' multiplexor that so offends people. OTOH, the master syscall mux
_is_ a typeless multiplexor... </sarcasm>
David
--
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