kernel-crypto.git - User-space crypto API development for Linux

	Commit message (Collapse)	Author	Age	Files	Lines
*	[PATCH] pgdat allocation and update for ia64 of memory hotplug: update pgdat ↵	Yasunori Goto	2006-06-27	1	-0/+12
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	address array This is to refresh node_data[] array for ia64. As I mentioned previous patches, ia64 has copies of information of pgdat address array on each node as per node data. At v2 of node_add, this function used stop_machine_run() to update them. (I wished that they were copied safety as much as possible.) But, in this patch, this arrays are just copied simply, and set node_online_map bit after completion of pgdat initialization. So, kernel must touch NODE_DATA() macro after checking node_online_map(). (Current code has already done it.) This is more simple way for just hot-add..... Note : It will be problem when hot-remove will occur, because, even if online_map bit is set, kernel may touch NODE_DATA() due to race condition. :-( Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
*	Don't include linux/config.h from anywhere else in include/	David Woodhouse	2006-04-26	1	-1/+0
\| \| \| \|	Signed-off-by: David Woodhouse <dwmw2@infradead.org>
*	[PATCH] V5 ia64 SPARSEMEM - conditional changes for SPARSEMEM	Bob Picco	2005-10-04	1	-2/+2
\| \| \| \| \| \| \| \| \| \|	This patch introduces the conditional changes required for the three memory models. With [patch 1/4] there are three memory models; FLATMEM, DISCONTIG and SPARSEMEM. Also a new arch include file sparemem.h is introduced for defining SPARSEMEM parameters. Signed-off-by: Bob Picco <bob.picco@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
*	Linux-2.6.12-rc2v2.6.12-rc2	Linus Torvalds	2005-04-16	1	-0/+52
	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!