litmus-rt.git - The LITMUS^RT kernel.

	Commit message (Collapse)	Author	Age
*	[XFS] Add lockdep support for XFS	Lachlan McIlroy	2007-05-07
\| \| \| \| \| \| \| \| \|	SGI-PV: 963965 SGI-Modid: xfs-linux-melb:xfs-kern:28485a Signed-off-by: Lachlan McIlroy <lachlan@sgi.com> Signed-off-by: David Chinner <dgc@sgi.com> Signed-off-by: Tim Shimmin <tes@sgi.com>
*	[XFS] mraccessf & mrupdatef are supposed to be the "flags" versions of the	Lachlan McIlroy	2007-02-10
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	functions, but they a) ignore the flags parameter completely, and b) are never called directly, only via the flag-less defines anyway So, drop the #define indirection, and rename mraccessf to mraccess, etc. SGI-PV: 959138 SGI-Modid: xfs-linux-melb:xfs-kern:27711a Signed-off-by: Lachlan McIlroy <lachlan@sgi.com> Signed-off-by: Eric Sandeen <sandeen@sandeen.net> Signed-off-by: Tim Shimmin <tes@sgi.com>
*	[XFS] lock validator: lockdep: small xfs init_rwsem() cleanup	Ingo Molnar	2006-06-09
\| \| \| \| \| \| \| \| \| \| \| \| \| \|	init_rwsem() has no return value. This is not a problem if init_rwsem() is a function, but it's a problem if it's a do { ... } while (0) macro. (which lockdep introduces) SGI-PV: 904196 SGI-Modid: xfs-linux-melb:xfs-kern:26082a Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Nathan Scott <nathans@sgi.com>
*	[XFS] We really suck at spulling. Thanks to Chris Pascoe for fixing all	Nathan Scott	2006-03-28
\| \| \| \| \| \| \| \| \|	these typos. SGI-PV: 904196 SGI-Modid: xfs-linux-melb:xfs-kern:25539a Signed-off-by: Nathan Scott <nathans@sgi.com>
*	[XFS] Update license/copyright notices to match the prefered SGI	Nathan Scott	2005-11-01
\| \| \| \| \| \| \| \| \|	boilerplate. SGI-PV: 913862 SGI-Modid: xfs-linux:xfs-kern:23903a Signed-off-by: Nathan Scott <nathans@sgi.com>
*	Linux-2.6.12-rc2v2.6.12-rc2	Linus Torvalds	2005-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!