From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: ALSA: remove magic cast (0/6) Date: Mon, 21 Jun 2004 19:16:52 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200406141555.i5EFtD7g013906@melkki.cs.helsinki.fi> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by alsa.alsa-project.org (ALSA's E-mail Delivery System) with ESMTP id 143E821A for ; Mon, 21 Jun 2004 19:16:55 +0200 (MEST) In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Pekka J Enberg Cc: Jaroslav Kysela , ALSA development List-Id: alsa-devel@alsa-project.org 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