All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@gmail.com>
To: Paulo Marques <pmarques@grupopie.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, 2 Feb 2005 09:23:48 +0200	[thread overview]
Message-ID: <84144f02050201232324bebb3f@mail.gmail.com> (raw)
In-Reply-To: <41FFB5A1.20100@grupopie.com>

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().

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.

                          Pekka

  reply	other threads:[~2005-02-02  7:23 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 [this message]
2005-02-02 12:17       ` Paulo Marques
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=84144f02050201232324bebb3f@mail.gmail.com \
    --to=penberg@gmail.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=pmarques@grupopie.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.