Re: [Alsa-devel] Re: [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver

[Takashi Iwai <tiwai@suse.de>]

At Wed, 21 Sep 2005 09:31:09 +0100,
Christoph Hellwig wrote:
> 
> On Tue, Sep 20, 2005 at 05:23:09PM -0700, Andrew Morton wrote:
> > > I'm not sure what to do. I'd be happy to take them out. But I woudn't
> > > mind leaving them in if that's what alsa convention is.
> > 
> > I'd be inclined to stick with the alsa style.  That's just an fyi if you
> > plan on working in other places.
> 
> I'd _really_ prefer to fix all of alsa.  Alsa is so full of wrappers
> and multiple names for the same thing that's it's almost impossibly
> for a normal kernel developer to fix anythign in there.

Oh I guess you're referring to the messy memory stuff in ALSA code?

(Or you mean about the foo_t style?  Then it would be easy to fix, and
 I'd appreciate if someone takes this job :)

Basically I agree with all your suggestions - hacks have been there
simply as workarounds.  They should be removed.

The following are in WIP on my local tree:

- Merge of dma_alloc_coherent() hacks for pages <32bit to kernel core
  (for i386 and ppc)

- PageReserve and mmaps:
  dma_mmap_coherent() will be used in all architectures instead of
  vma nopage callback.  Of course, dma_mmap_coherent() should be
  ported to all archs.

- Removal of the common allocator in sound/core/memalloc.c
  Instead, each driver has alloc_buffer() and free_buffer()
  callbacks. 

  (The reason to have callbacks is that the buffers can be allocated in
   3 places: by the pre-allocator, by proc control and at each open /
   hw_params setup.)


What I'm still considering are:

- The "right" way to allocate/mmap coherent SG-buffers.
- A common API for mmap vmalloc buffers.
- Subsystem or module-wide check of memory leaks in slab
  (the notorious kmalloc wrapper)

Please let me know if you have any good solutions, comments or
suggestions for the above.


thanks,

Takashi