All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Pekka Enberg <penberg@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, penberg@cs.helsinki.fi
Subject: Re: [PATCH 2.6] 1/7 create kstrdup library function
Date: Wed, 02 Feb 2005 12:17:23 +0000	[thread overview]
Message-ID: <4200C4D3.9060805@grupopie.com> (raw)
In-Reply-To: <84144f02050201232324bebb3f@mail.gmail.com>

Pekka Enberg wrote:
> At some point in time, I wrote:
> 
>>>kstrdup() is a special-case _memory allocator_ (not so much a string
>>>operation) so I think it should go into mm/slab.c where we currently
>>>have kcalloc().
> 
> 
> On Tue, 01 Feb 2005 17:00:17 +0000, Paulo Marques <pmarques@grupopie.com> wrote:
> 
>>I was following Rusty Russell's approach. Also, I believe this is more
>>intuitive because the standard libc strdup function is declared in string.h.
>>
>>However, I really don't have strong feelings either way, so if the
>>majority agrees that this should be in mm/slab, its fine by me.
> 
> 
> Intuitive, perhaps, but I think it's wrong. I don't like it because it
> makes string operations depend on slab. Furthermore, kstrdup() is not
> a string operation. It is about memory allocation, really, just like
> kcalloc().

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.

> One possible way to clean this up would be to extract the
> standard-like allocators (kmalloc, kcalloc, and kstrdup) from
> mm/slab.c and move them into a separate file.

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.

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 :)

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

  reply	other threads:[~2005-02-02 12:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-01  3:28 [PATCH 2.6] 1/7 create kstrdup library function pmarques
2005-02-01 16:44 ` Pekka Enberg
2005-02-01 17:00   ` Paulo Marques
2005-02-02  7:23     ` Pekka Enberg
2005-02-02 12:17       ` Paulo Marques [this message]
2005-02-02 12:29         ` Pekka J Enberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4200C4D3.9060805@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=penberg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.