mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
Signed-off-by: Tetsuo Handa <[email protected]>
---
mm/slab.c | 1 +
mm/slob.c | 1 +
2 files changed, 2 insertions(+)
--- linux-2.6-mm.orig/mm/slab.c
+++ linux-2.6-mm/mm/slab.c
@@ -4479,3 +4479,4 @@ size_t ksize(const void *objp)
return obj_size(virt_to_cache(objp));
}
+EXPORT_SYMBOL(ksize);
--- linux-2.6-mm.orig/mm/slob.c
+++ linux-2.6-mm/mm/slob.c
@@ -495,6 +495,7 @@ size_t ksize(const void *block)
else
return sp->page.private;
}
+EXPORT_SYMBOL(ksize);
struct kmem_cache {
unsigned int size, align;
On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
>
> mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
>...
That's due to the fact that my patch to remove this unused export from
slub was not yet applied...
Where is the modular in-kernel user?
cu
Adrian
--
"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 Seed
Hello.
Adrian Bunk wrote:
> > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
> That's due to the fact that my patch to remove this unused export from
> slub was not yet applied...
So, removing exports is intended thing?
> Where is the modular in-kernel user?
I don't know.
But I think ksize() should be available to kernel modules as well as kmalloc() etc.
Thanks.
Em Mon, Dec 03, 2007 at 06:34:20AM +0900, Tetsuo Handa escreveu:
> Hello.
>
> Adrian Bunk wrote:
> > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
> > That's due to the fact that my patch to remove this unused export from
> > slub was not yet applied...
> So, removing exports is intended thing?
The ones that are leftovers from past, valid, uses, yes. Kudos to Adrian
for being the zealot in action!
> > Where is the modular in-kernel user?
> I don't know.
> But I think ksize() should be available to kernel modules as well as kmalloc() etc.
Why do you think so? You have to justify that with some valid use.
- Arnaldo
Hello.
Arnaldo Carvalho de Melo wrote:
> > But I think ksize() should be available to kernel modules as well as kmalloc() etc.
> Why do you think so? You have to justify that with some valid use.
Is there an alternative function?
If not, it sounds to me that this is a regression.
We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era.
But are we going back to 2.4 era for out-of-tree kernel modules?
Thanks.
On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Arnaldo Carvalho de Melo wrote:
> > > But I think ksize() should be available to kernel modules as well as kmalloc() etc.
> > Why do you think so? You have to justify that with some valid use.
> Is there an alternative function?
The question is not whether there's an alternative function.
The kernel does not waste memory for all users by providing a fixed API
for external modules, the purpose of the kernel is to provide everything
required for what is shipped with the kernel.
Simply send the patch adding the exports when you submit your module for
inclusion in the kernel.
> If not, it sounds to me that this is a regression.
That sounds strange considering that slab and slob AFAIR never exported
this symbol and only slub in 2.6.22 and 2.6.23 exports it.
> We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era.
> But are we going back to 2.4 era for out-of-tree kernel modules?
The interesting fact is that there are zero in-kernel modules using it.
> Thanks.
cu
Adrian
--
"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 Seed
Hi,
On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
> > We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era.
> > But are we going back to 2.4 era for out-of-tree kernel modules?
On Dec 3, 2007 3:57 PM, Adrian Bunk <[email protected]> wrote:
> The interesting fact is that there are zero in-kernel modules using it.
Yeah, and now that we have krealloc() I don't expect that many callers
actually need ksize() either.
Pekka
On Mon, Dec 03, 2007 at 04:07:33PM +0200, Pekka Enberg wrote:
> Hi,
>
> On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
> > > We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era.
> > > But are we going back to 2.4 era for out-of-tree kernel modules?
>
> On Dec 3, 2007 3:57 PM, Adrian Bunk <[email protected]> wrote:
> > The interesting fact is that there are zero in-kernel modules using it.
>
> Yeah, and now that we have krealloc() I don't expect that many callers
> actually need ksize() either.
Yes, most of them ought not exist.
--
Mathematics is the supreme nostalgia of our time.
On Sun, 2 Dec 2007 14:48:42 +0100
Adrian Bunk <[email protected]> wrote:
> On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
> >
> > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
> >...
>
> That's due to the fact that my patch to remove this unused export from
> slub was not yet applied...
>
> Where is the modular in-kernel user?
>
binfmt_flat.c, binfmt_elf_fdpic.c.
On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote:
> On Sun, 2 Dec 2007 14:48:42 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
> > >
> > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
> > >...
> >
> > That's due to the fact that my patch to remove this unused export from
> > slub was not yet applied...
> >
> > Where is the modular in-kernel user?
> >
>
> binfmt_flat.c, binfmt_elf_fdpic.c.
I could have sworn I had checked that both are bools, but BINFMT_FLAT is
actually a tristate.
Is anyone actually using binfmt_flat modular (considering it's only
available for !MMU embedded systems)? If yes, then only exporting
ksize() will not be enough for getting it working modular...
cu
Adrian
--
"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 Seed
On Thu, Dec 06, 2007 at 10:02:48PM +0100, Adrian Bunk wrote:
> On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote:
> > On Sun, 2 Dec 2007 14:48:42 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> > > On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
> > > >
> > > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
> > > >...
> > >
> > > That's due to the fact that my patch to remove this unused export from
> > > slub was not yet applied...
> > >
> > > Where is the modular in-kernel user?
> > >
> >
> > binfmt_flat.c, binfmt_elf_fdpic.c.
>
> I could have sworn I had checked that both are bools, but BINFMT_FLAT is
> actually a tristate.
>
> Is anyone actually using binfmt_flat modular (considering it's only
> available for !MMU embedded systems)? If yes, then only exporting
> ksize() will not be enough for getting it working modular...
Considering it even lacks a MODULE_LICENSE("GPL") I do very much suspect
it simply lacks any use case.
cu
Adrian
--
"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 Seed
A couple of Cc:s added.
Adrian Bunk wrote:
> On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote:
>> On Sun, 2 Dec 2007 14:48:42 +0100
>> Adrian Bunk <[email protected]> wrote:
>>
>>> On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
>>>> mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
>>>> ...
>>> That's due to the fact that my patch to remove this unused export from
>>> slub was not yet applied...
>>>
>>> Where is the modular in-kernel user?
>>>
>> binfmt_flat.c, binfmt_elf_fdpic.c.
>
> I could have sworn I had checked that both are bools, but BINFMT_FLAT is
> actually a tristate.
>
> Is anyone actually using binfmt_flat modular (considering it's only
> available for !MMU embedded systems)? If yes, then only exporting
> ksize() will not be enough for getting it working modular...
We're not using modular binfmt_flat on the Blackfin, but I can't speak
for other architectures.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Bernd Schmidt wrote:
> A couple of Cc:s added.
>
> Adrian Bunk wrote:
>> On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote:
>>> On Sun, 2 Dec 2007 14:48:42 +0100
>>> Adrian Bunk <[email protected]> wrote:
>>>
>>>> On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
>>>>> mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
>>>>> ...
>>>> That's due to the fact that my patch to remove this unused export from
>>>> slub was not yet applied...
>>>>
>>>> Where is the modular in-kernel user?
>>>>
>>> binfmt_flat.c, binfmt_elf_fdpic.c.
>> I could have sworn I had checked that both are bools, but BINFMT_FLAT is
>> actually a tristate.
>>
>> Is anyone actually using binfmt_flat modular (considering it's only
>> available for !MMU embedded systems)? If yes, then only exporting
>> ksize() will not be enough for getting it working modular...
>
> We're not using modular binfmt_flat on the Blackfin, but I can't speak
> for other architectures.
I don't know of any architectures that do (or have ever) used
these as modules.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [email protected]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com