Re: [PATCH] ALSA: remove magic cast (0/6)

[Takashi Iwai <tiwai@suse.de>]

At Mon, 14 Jun 2004 20:18:31 +0200 (CEST),
Jaroslav wrote:
> 
> On Mon, 14 Jun 2004, Takashi Iwai wrote:
> 
> > > This patch remove snd_magic_cast from the kernel.  It's on top of the
> > > kcalloc() patch and was compile-tested with allyesconfig.
> > 
> > Thanks for the patch.
> > 
> > Did you already make a patch to remove hidden_kmalloc and
> > hidden_vmalloc wrappers, or do I miss it?  They are also suprefluous.
> > 
> > Jaroslav, what do you think about removing kmalloc/vmalloc wrappers
> > and magic stuffs from the kernel tree?
> > 
> > For me, it's ok to remove them from the linux kernel tree
> > (ie. alsa-kernel tree).  I agree that they are not needed for the
> > matured drivers.  For the experimental drivers, We can provide another
> > type check mechanism in alsa-driver tree locally.
> 
> I think that we need to separate the patch:
> 
> 1) removal of own memory pool (check for memory leaks)
> 2) magic stuff
> 
> The structure mistakes usually ends with an oops, but the memory leaks 
> cannot be detected easy inside the kernel.

IMO, the memory leak check should be better in slab rather than in
ALSA wrapper.  I understand that has annoyed people.

Having ALSA-specific isn't always nice, for example, we have to have
kfree() and kfree_nocheck(), and this has triggered some bugs.

About vmalloc(), we need to reconsider the memory check, too.  Many
routines assume that the vmalloc data is aligned to the page, but the
hidden header breaks this.


> 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?

Agreed.  The memory leak check is useful.
A general solution would be better...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND