From: Takashi Iwai <tiwai@suse.de>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: Jaroslav Kysela <perex@suse.cz>,
ALSA development <alsa-devel@alsa-project.org>
Subject: Re: ALSA: remove magic cast (0/6)
Date: Mon, 21 Jun 2004 19:16:52 +0200 [thread overview]
Message-ID: <s5hu0x4ltkr.wl@alsa2.suse.de> (raw)
In-Reply-To: <courier.40CE9975.00001489@courier.cs.helsinki.fi>
At Tue, 15 Jun 2004 09:38:45 +0300,
Pekka J Enberg wrote:
>
> Hi,
>
> Jaroslav Kysela writes:
> > I think that we need to separate the patch:
> >
> > 1) removal of own memory pool (check for memory leaks)
> > 2) magic stuff
>
> I only replaced snd_kcalloc() and snd_magic_kcalloc() with the new generic
> kcalloc() and removed snd_magic_cast so the kmalloc wrappers are still in
> place.
I agree with Jaroslav. To make the things easy, let's split the
patch.
1. addition of kcalloc()
2. replacement of snd_kcalloc with kcalloc
3. removal of magic stuff
- replace snd_magic_kmalloc/kcalloc to kmalloc/kcalloc.
- replace snd_magic_kfree to kfree.
- replace snd_magic_cast to normal cast.
- remove the rest of magic-related codes/files.
Then only the memory tracking (called memory pool in above) will remain.
> Jaroslav Kysela writes:
> > I don't like too much the idea to remove the own memory pool in the debug
> > mode. It helped me in past numerous times and I think that ALSA is one
> > from the clean subsystems in this area. I don't understand the kernel
> > developers - there is no replacement. Yes, it's good only for debugging,
> > but why not make debugging easier for other developers as well with
> > proposing a general solution?
>
> What memory pool? To me, it looks like sound/core/memory.c just maintains a
> list of kmallocs and vmallocs we check when snd_memory_done() is called.
Jaroslav mentioned this, too.
> Perhaps we could make it somehow automagically per-module for debug builds
> to make it generic? Memory leak check could be done at module_exit.
I thought of a similar thing. It will be more useful to make it
generic.
For now, until the generic debug code like the above is implmented in
the generic slab/kmalloc layer, we can keep it inside the ALSA.
We can safely clean up the other stuff beforehand.
How about this?
Takashi
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
next prev parent reply other threads:[~2004-06-21 17:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200406141555.i5EFtD7g013906@melkki.cs.helsinki.fi>
[not found] ` <s5hk6yadspp.wl@alsa2.suse.de>
2004-06-14 18:18 ` [PATCH] ALSA: remove magic cast (0/6) Jaroslav Kysela
2004-06-15 9:38 ` Takashi Iwai
[not found] ` <courier.40CE9975.00001489@courier.cs.helsinki.fi>
2004-06-21 17:16 ` Takashi Iwai [this message]
[not found] ` <courier.40D7C8C5.00001480@courier.cs.helsinki.fi>
2004-06-22 16:38 ` Takashi Iwai
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=s5hu0x4ltkr.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=penberg@cs.helsinki.fi \
--cc=perex@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox