- 09 2月, 2008 1 次提交
-
-
由 Mike Frysinger 提交于
Per previous discussions about cleaning up ufs_fs.h, people just want this straight up dropped from userspace export. The only remaining consumer (silo) has been fixed a while ago to not rely on this header. This allows use to move it completely from include/linux/ to fs/ufs/ seeing as how the only in-kernel consumer is fs/ufs/. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Cc: Jan Kara <jack@ucw.cz> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 10月, 2007 1 次提交
-
-
由 Christoph Hellwig 提交于
Move prototypes and in-core structures to fs/ufs/ similar to what most other filesystems already do. I made little modifications: move also ufs debug macros and mount options constants into fs/ufs/ufs.h, this stuff also private for ufs. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NEvgeniy Dushistov <dushistov@mail.ru> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 10 7月, 2007 1 次提交
-
-
由 Jens Axboe 提交于
They can use generic_file_splice_read() instead. Since sys_sendfile() now prefers that, there should be no change in behaviour. Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
- 01 10月, 2006 1 次提交
-
-
由 Badari Pulavarty 提交于
This patch cleans up generic_file_*_read/write() interfaces. Christoph Hellwig gave me the idea for this clean ups. In a nutshell, all filesystems should set .aio_read/.aio_write methods and use do_sync_read/ do_sync_write() as their .read/.write methods. This allows us to cleanup all variants of generic_file_* routines. Final available interfaces: generic_file_aio_read() - read handler generic_file_aio_write() - write handler generic_file_aio_write_nolock() - no lock write handler __generic_file_aio_write_nolock() - internal worker routine Signed-off-by: NBadari Pulavarty <pbadari@us.ibm.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 7月, 2006 1 次提交
-
-
由 Evgeniy Dushistov 提交于
This patch fixes buggy behaviour of UFS in such kind of scenario: open(, O_TRUNC...) ftruncate(, 1024) ftruncate(, 0) Such a scenario causes ufs_panic and remount read-only. This happen because of according to specification UFS should always allocate block for last byte, and many parts of our implementation rely on this, but `ufs_truncate' doesn't care about this. To make possible return error code and to know about old size, this patch removes `truncate' from ufs inode_operations and uses `setattr' method to call ufs_truncate. Signed-off-by: NEvgeniy Dushistov <dushistov@mail.ru> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 6月, 2006 1 次提交
-
-
由 Evgeniy Dushistov 提交于
Presently ufs doesn't support "fsync", this make some applications unhappy, for example vim. This patch fixes this situation. Signed-off-by: NEvgeniy Dushistov <dushistov@mail.ru> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 29 3月, 2006 1 次提交
-
-
由 Arjan van de Ven 提交于
This is a conversion to make the various file_operations structs in fs/ const. Basically a regexp job, with a few manual fixups The goal is both to increase correctness (harder to accidentally write to shared datastructures) and reducing the false sharing of cachelines with things that get dirty in .data (while .rodata is nicely read only and thus cache clean) Signed-off-by: NArjan van de Ven <arjan@infradead.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 23 3月, 2006 1 次提交
-
-
由 Alexey Dobriyan 提交于
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-