Re: 1/7 create kstrdup library function

[Pekka J Enberg]

Paulo Marques writes:
> I agree with the "is like kcalloc" argument in the sense that it does an 
> allocation + something else. But in this case the "something else" is in 
> fact a string operation, so this just seem to be in the middle.

Sure, but now you're forcing all users of <string.h> to depend on the slab 
as well. Conceptually, kstrdup() is an initializing memory allocator, not a 
string operation, which is why I think it should go into slab.c. 

Paulo Marques writes:
> I don't like this approach. From a quick grep you get 4972 kmalloc's in .c 
> files in the kernel tree and only 35 kstrdup's. Moving kstrdup around is 
> still just 7 patches, kmalloc is a much bigger problem.

Hmm? Yes, moving the declaration from slab.h to some other header is 
painful. I only talked about moving the definition from slab.c. 

Paulo Marques writes:
> Anyway, as I said before, if more people believe that moving kstrdup into 
> mm/slab.c is the way to go, then its fine by me. The problem I was trying 
> to solve was having several versions of strdup-like functions all around 
> the kernel, and this problem gets fixed either way. Right now, the poll 
> goes something like this: 
>
> string.c: me, Rusty Russell
> slab.c: Pekka Enberg 
>
> I think we need more votes :)

Could we also get Rusty's confirmation on this? 

      Pekka 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/