RFC - Clean up of ALSA kernel codes

RFC - Clean up of ALSA kernel codes

[Takashi Iwai]

Hi,

currently I'm working on clean up of ALSA kernel side codes.
There have been complaints from kernel developers about the ALSA's
own-styles, and I'm trying to reduce them.

My plan is like below:

1. Clean up of kmalloc/vmalloc wrappers

1a. Removal of vmalloc wrapper

   The vmalloc wrapper breaks the alignment of page size, which has
   many side effects.  So let's remove this.

1b. Move kmalloc wrapper to alsa-driver tree

   Remove kmalloc wrapper from alsa-kernel tree, but put it to
   alsa-driver tree, so that we can still check the memory leak with
   own build.

   *_nocheck() should be removed from alsa-kernel.  Since most of 
   kfree_nocheck() is bound with release_resource(), I'll introduce
   release_and_free_resource() funciton to simplify.

2. Removal of snd_runtime_check()

   snd_runtime_check() worsens the flow visibility.
   It should be either a check-only like snd_assert(), or a simple
   if condition with snd_BUG().

3. Removal of snd_timestamp_*

   Use normal functions like getnstimeofday().

4. Removal of the main memory allocators

   Introduce alloc_buffer() and free_buffer() callbacks, and let each
   driver to allocate buffers using dma_alloc_coherent(), etc.
   This will reduce snd_alloc_*() allocators in memalloc.c.

5. Reprogram SG-buffer handlers

   Use dma_map_sg() for sg-buffers, so that the non-consistent
   allocator can be used, e.g. vmalloc_32().
   For devices with DMA mask less than 32bit (e.g. trident, emu10k1),
   a new function may be required to allocate pages in the given DMA
   mask.

6. Use dma_mmap_coherent() on all architectures

   Once after dma_mmap_coherent() is implemented on all architectures,
   we can get rid of nopage stuff.  It's more straightforward.
   (This requires the handling of reserved pages, so wait until the
   remove-page-reserve patch is accepted.)


I already have done up to 3 on my local tree, and ready to commit.
4, 5 and 6 are work in progress.


As additional items:

7. Removal of xxx_t styles (use struct xxx, instead)
8. Clean up proc fs handlers

They are in lower priorities, so will do if I have enough time left.


If you have any objections, comments or suggestions, please let me
know.  I'd like to start committing from tomorrow or next week.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: RFC - Clean up of ALSA kernel codes

[Martin Habets]

Takashi,

I applaud you for doing this. An additional item I can think of is
a call to authors to make sure the first printk argument is correct.
i.e.:
	printk(KERN_INFO "lvi_frag...
in stead of
	printk("lvi_frag...

On a related note: Is there a MAINTAINERS list for alsa drivers? Should
there be? Or should we use the one in the linux kernel?

Last but not least, I am personally confused when to use snd_printk,
snd_printd, snd_printdd or regular printk. On top of that there are
different debugging macros in different drivers. I'd appreciate any
guidelines you could give on this.

Martin

On Thu, Oct 06, 2005 at 02:29:46PM +0200, Takashi Iwai wrote:
> Hi,
> 
> currently I'm working on clean up of ALSA kernel side codes.
> There have been complaints from kernel developers about the ALSA's
> own-styles, and I'm trying to reduce them.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: RFC - Clean up of ALSA kernel codes

[Takashi Iwai]

At Fri, 7 Oct 2005 15:31:58 +0100,
Martin Habets wrote:
> 
> Takashi,
> 
> I applaud you for doing this. An additional item I can think of is
> a call to authors to make sure the first printk argument is correct.
> i.e.:
> 	printk(KERN_INFO "lvi_frag...
> in stead of
> 	printk("lvi_frag...

Good point.

> On a related note: Is there a MAINTAINERS list for alsa drivers? Should
> there be? Or should we use the one in the linux kernel?

Yes, that's a missing one currently in alsa-kernel tree.
There is a file alsa-driver/doc/SOUNDCARDS.  But it's really
outdated... 

IMO, it's better to use kernel MAINTAINERS.  The only tiny problem is
that it's not in alsa-kernel tree directory per se.

> Last but not least, I am personally confused when to use snd_printk,
> snd_printd, snd_printdd or regular printk. On top of that there are
> different debugging macros in different drivers. I'd appreciate any
> guidelines you could give on this.

I think it's OK in general to use the normal printk() everywhere
instead of snd_printk().  snd_printk() can give you more precise place
(file and line) with a config option, so it might be more helpful for
debugging.  But for the general error/informational messages, printk()
would suffice if a proper prefix is given (e.g. "driver-foo: ERROR
xxx").

snd_printd() is for debugging.  snd_printdd() is for more deeper
debugging :)

Note that many distros turn on CONFIG_SND_DEBUG=yes, i.e. snd_printd()
is enabled.  So, snd_printd() shouldn't be used for the purpose to
spit out logs too often.  For such, use snd_printdd().


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

RFC - Clean up of ALSA kernel codes

[Tom Watson]

In your message you mentioned:
"8. Clean up proc fs handlers".

My only idea is to make the /proc stuff a little more "page friendly".  Many
of the register dumps are one register per line.  It is a bit easier (in my
opinion) to have them say 8 register values per line.  It makes the things
easier to read, and refer without scrolling back and forth.  As an example
(not limited to JUST this sound card): /proc/asound/V8235/via82xx produces
over 40 lines of register data.  It could have just as easily been formatted
horizontally and be at a minimum 1/4 of the number of lines.

Yes, this is a picky item, but having register data in a nice readable format
makes for nicer debugging.  Obviously this is not a "high priority" item, as
the current setup does function.  I will leave it to others to determine the
priority of such a change.

I do have a driver in the planning stages, and my intent is to make the /proc
printouts "nicely formatted".  We shall see when I publish the driver which
is one of those "real soon now" (in the works for 2+ years) things.

Just random thoughts.

-- 
Tom Watson
tsw@johana.com


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: RFC - Clean up of ALSA kernel codes

[Jaroslav Kysela]

On Thu, 6 Oct 2005, Tom Watson wrote:

> In your message you mentioned:
> "8. Clean up proc fs handlers".
> 
> My only idea is to make the /proc stuff a little more "page friendly".  
> Many of the register dumps are one register per line.  It is a bit 
> easier (in my opinion) to have them say 8 register values per line.  It 

I don't agree here. We have a lot text utilities (grep, awk etc.) which 
can be used to filter the registers for which one looks for. Having them 
mixed on one line means more mess (and you need the datasheet to check 
offsets by hand).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: RFC - Clean up of ALSA kernel codes

[Takashi Iwai]

At Fri, 7 Oct 2005 09:16:44 +0200 (CEST),
Jaroslav wrote:
> 
> On Thu, 6 Oct 2005, Tom Watson wrote:
> 
> > In your message you mentioned:
> > "8. Clean up proc fs handlers".
> > 
> > My only idea is to make the /proc stuff a little more "page friendly".  
> > Many of the register dumps are one register per line.  It is a bit 
> > easier (in my opinion) to have them say 8 register values per line.  It 
> 
> I don't agree here. We have a lot text utilities (grep, awk etc.) which 
> can be used to filter the registers for which one looks for. Having them 
> mixed on one line means more mess (and you need the datasheet to check 
> offsets by hand).

Yep.  (But rhetorically it's true in the reverse way, too ;)

One of the merits with one-register-per-line is that you can easiy
find out the changes by grep.  Imagine you have register snapshots and
compare them.

Regarding /proc:

Some opinions are to move /proc stuff to /sys.  But I have no strong
reason to do this yet, especially since /sys is not ordered
beautifully now as it was supposed to be.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl