aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/coda_psdev.h
Commit message (Collapse)AuthorAge
* headers_check fix cleanup: linux/coda_psdev.hJaswinder Singh Rajput2009-02-03
| | | | | | | | | These are only for kernel internals as pointed by Arnd Bergmann: struct kstatfs struct venus_comm coda_vcp() Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
* headers_check fix: linux/coda_psdev.hJaswinder Singh Rajput2009-02-02
| | | | | | | | fix the following 'make headers_check' warning: usr/include/linux/coda_psdev.h:90: extern's make no sense in userspace Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
* coda: remove CODA_STORE/CODA_RELEASE upcallsJan Harkes2007-07-21
| | | | | | | | | | | | | | | | | | | | | | | This is an variation on the patch sent by Christoph Hellwig which kills file_count abuse by the Coda kernel module by moving the coda_flush functionality into coda_release. However part of reason we were using the coda_flush callback was to allow Coda to pass errors that occur during writeback from the userspace cache manager back to close(). As Al Viro explained on linux-fsdevel, it is impossible to guarantee that such errors can in fact be returned back to the caller. There are many cases where the last reference to a file is not released by the close system call and it is also impossible to pick some close as a 'last-close' and delay it until all other references have been destroyed. The CODA_STORE/CODA_RELEASE upcall combination is clearly a broken design, and it is better to remove it completely. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@ftp.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* coda: remove statistics counters from /proc/fs/codaJan Harkes2007-07-19
| | | | | | | | Similar information can easily be obtained with strace -c. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* coda: remove struct coda_sb_infoJan Harkes2007-07-19
| | | | | | | | | The sb_info structure only contains a single pointer to the character device, there is no need for the added indirection. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* coda: block signals during upcall processingJan Harkes2007-07-19
| | | | | | | | | | We ignore signals for about 30 seconds to give userspace a chance to see the upcall. As we did not block signals we ended up in a busy loop for the remainder of the period when a signal is received. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Move several *_SUPER_MAGIC symbols to include/linux/magic.h.Jeff Garzik2006-09-24
| | | | Signed-off-by: Jeff Garzik <jeff@garzik.org>
* [PATCH] VFS: Permit filesystem to perform statfs with a known root dentryDavid Howells2006-06-23
| | | | | | | | | | | | | | | | | | | | | Give the statfs superblock operation a dentry pointer rather than a superblock pointer. This complements the get_sb() patch. That reduced the significance of sb->s_root, allowing NFS to place a fake root there. However, NFS does require a dentry to use as a target for the statfs operation. This permits the root in the vfsmount to be used instead. linux/mount.h has been added where necessary to make allyesconfig build successfully. Interest has also been expressed for use with the FUSE and XFS filesystems. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Nathan Scott <nathans@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!