linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2011-01-12	switch hpfs	Al Viro	1	-6/+1
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-01-07	fs: dcache reduce branches in lookup path	Nick Piggin	1	-1/+1
	Reduce some branches and memory accesses in dcache lookup by adding dentry flags to indicate common d_ops are set, rather than having to check them. This saves a pointer memory access (dentry->d_op) in common path lookup situations, and saves another pointer load and branch in cases where we have d_op but not the particular operation. Patched with: git grep -E '[.>]([[:space:]])d_op([[:space:]])=' \| xargs sed -e 's/\([^\t ]\)->d_op = \(.\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]\)\.d_op = \(.\);/d_set_d_op(\&\1, \2);/' -i Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07	fs: change d_hash for rcu-walk	Nick Piggin	1	-1/+2
	Change d_hash so it may be called from lock-free RCU lookups. See similar patch for d_compare for details. For in-tree filesystems, this is just a mechanical change. Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07	fs: change d_compare for rcu-walk	Nick Piggin	1	-8/+14
	Change d_compare so it may be called from lock-free RCU lookups. This does put significant restrictions on what may be done from the callback, however there don't seem to have been any problems with in-tree fses. If some strange use case pops up that _really_ cannot cope with the rcu-walk rules, we can just add new rcu-unaware callbacks, which would cause name lookup to drop out of rcu-walk mode. For in-tree filesystems, this is just a mechanical change. Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2010-03-03	sanitize signedness/const for pointers to char in hpfs a bit	Al Viro	1	-6/+8
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2009-03-27	constify dentry_operations: misc filesystems	Al Viro	1	-1/+1
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+60
	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!