summaryrefslogtreecommitdiff
path: root/include/linux/ufs_fs_sb.h
AgeCommit message (Collapse)AuthorFilesLines
2007-10-17ufs: move non-layout parts of ufs_fs.h to fs/ufs/Christoph Hellwig1-37/+0
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: Christoph Hellwig <hch@lst.de> Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12[PATCH] export ufs_fs.h to userspaceMike Frysinger1-1/+0
Was ufs_fs.h purposefully not exported to userspace or did it just slip through the cracks ? assuming the latter scenario, the attached patch touches up the relationship between ufs_fs.h and its sub headers (like ufs_fs_sb.h) so that we can export it ... the silo bootloader takes advantage of this header for example. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-02-03[PATCH] ufs: fix oops with `ufs1' typeEvgeniy Dushistov1-1/+1
"rm" command, on file system with "ufs1" type cause system hang up. This is, in fact, not so bad as it seems to be, because of after that in "kernel control path" there are 3-4 places which may cause "oops". So the first patch fix oopses, and the second patch fix "kernel hang up". "oops" appears because of reading of group's summary info partly wrong, and access to not first group's summary info cause "oops". Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+38
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!