mm/slab: unexport kmem_cache_alloc_node
PATCH 1/1 mm/slab: unexport kmem_cache_alloc_node
I didn't find any modular usage of kmem_cache_alloc_node.
---
This patch was already sent on:
- 2 Jul 2005
- 21 Jun 2005
- 30 May 2005
- 15 May 2005
mm/slab.c renamed from mm/slab.c.old +0 -1
@@ -2431,7 +2440,6 @@ __builtin_return_address(0)); return objp; } -EXPORT_SYMBOL (kmem_cache_alloc_node);#endif
Quoted 5 lines · Adrian Bunk
I didn't find any modular usage of
kmem_cache_alloc_node.Signed-off-by Adrian Bunk <[email protected]>
Quoted 7 lines
---
This patch was already sent on:
- 2 Jul 2005
- 21 Jun 2005
- 30 May 2005
- 15 May 2005
Yeah, I've been ducking that one.
mm/slab.c line 2444
Quoted 9 lines
mm/slab.c renamed from mm/slab.c.old +0
-1@@ -2431,7 +2440,6 @@ __builtin_return_address(0)); return objp; } -EXPORT_SYMBOL (kmem_cache_alloc_node);#endif
Even though we don't currently have in-module users, we probably will do so soon and it's a part of the slab API and the slab API is exported to modules. I don't see much point in partially-exporting the API and applying a patch which we'll soon revert.
Christoph?
Quoted 4 lines · Andrew Morton
Quoted 4 lines
mm/slab.c renamed from mm/slab.c.old +0
-1return objp; } -EXPORT_SYMBOL (kmem_cache_alloc_node);
Quoted 9 lines
Quoted 1 line
#endif
Even though we don't currently have in-module users, we probably will do so soon and it's a part of the slab API and the slab API is exported to modules. I don't see much point in partially-exporting the API and applying a patch which we'll soon revert.
Christoph?
I fully agree. Drivers will have to use that call in the future in order to properly place their control structures. The e1000 in your tree already does so and may be compiled as a module. Thus applying this patch will break mm.
Quoted 13 lines · Christoph Lameter
Quoted 11 lines · Andrew Morton
mm/slab.c line 2444
Quoted 5 lines
mm/slab.c renamed from mm/slab.c.old +0
-1return objp; } -EXPORT_SYMBOL (kmem_cache_alloc_node);#endif Even though we don't currently have in-module users, we probably will do so soon and it's a part of the slab API and the slab API is exported to modules. I don't see much point in partially-exporting the API and applying a patch which we'll soon revert.
Quoted 7 lines
Quoted 2 lines
Christoph?
I fully agree. Drivers will have to use that call in the future in order to properly place their control structures. The e1000 in your tree already does so and may be compiled as a module. Thus applying this patch will break mm.
I don't see e1000 in 2.6.13-rc3-mm2 using it.
And yes, I tried compilation of as much as possible (including e1000) in 2.6.13-rc3-mm2 with my patch applied before resending it.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 6 lines · Adrian Bunk
Quoted 4 lines
I fully agree. Drivers will have to use that call in the future in order to properly place their control structures. The e1000 in your tree already does so and may be compiled as a module. Thus applying this patch will break mm.
I don't see e1000 in 2.6.13-rc3-mm2 using it.
Hmmm. Ok. e1000 only uses kmalloc_node which is based on kmem_cache_alloc_node. However, kmalloc_node will likely become a macro like kmalloc.
Applying the patch would mean that modules would only be able to use kmalloc_node and not able to allocate node specific memory from one of the slab caches.