Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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