Messages in this thread | | | Date | Thu, 29 Sep 2005 15:21:43 +0200 | From | Takashi Iwai <> | Subject | Re: [Alsa-devel] Re: [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |