Re: [alsa-devel] how do you people debug ALSA?
"Mihaela Vitalariu" <admiralwolverine@gmail.com> wrote:
I meant what tools do you use, what Debuggers? In my post i wasn't complaining about ALSA, i was just curios about the debugging tools that you use, from a developer's standpoint...
The group that I'm working with (to develop an alsa driver for the Gadget Labs soundcard) would be very interested in any input on this subject. The team is made up of skilled C/C++ coders, but there is very little to no experience with writing a linux hardware driver. It would be fine to say "vi is the development environment, and we sprinkle the code with printk statements and take them out when the soup's done". It would save us a lot of overhead in figuring out the best way to get on the same page with each other since it's a pretty new team. Any other words of wisdom from those who've been there would be very welcomed and appreciated. If you use KDE, Eclipse, or something else, that's fine too. Some particular questions (in no particular order): 1. Do you regularly use the "alsasound" kernel function during development so you can take the driver in and out of the kernel? If it's used, is is used from the beginning or in the last stages of development? (I'm not sure if it's alsasound, sndconfig, etc). 2. Are the process statements given in the 'How-To' (snd_printk, snd_assert, snd_BUG) the main ones or are there others that are 'pre-built' and widely useful? http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1696.htm 3. Are there tools that are almost always used when writing a sound card driver like gdb, ddd, etc? 4. Since it's easy to do, is an interface into the proc file system useful from the start? http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1493.htm 5. Is the alsa wiki on debugging the sum total of what's needed or is there more we don't know about? (and we don't know that much!!) http://www.alsa-project.org/main/index.php/Driver_Compilation Of course, I could bring up the current Hot and Burning question we have (they are more important now): http://wavepro-driver.svn.sourceforge.net/viewvc/wavepro-driver/ 1. We've having difficulty getting the Altera PLD to load. Any suggestions on how to do this, how people without cards can help, an easy way to know when you are successful, or an incremental approach to the problem? 2. The GL card is powered from an Altera PLD (FPGA) (it has similar function as the Envy ICE chip once it's loaded). For the card to function at all, the Altera PLD has to be loaded when power is applied to the computer. Should the 'load the Altera' function be part of the alsa driver, part of alsa firmware, or should we just load it up when the computer boots (not in alsa)? 3. We're planning on using FC8/PlanetCCRMA as a 'beta test' environment. I've just noticed the new FC8 specific instructions on how to overcome my many bad habits when fooling around with the kernel. I'm putting it here for reference so I don't forget it (like I just did when trying to figure out if it was alsasound, procsound, or whatever to unload the driver). http://fedoraproject.org/wiki/Docs/CustomKernel If you would like to just put your two cents worth in to the very small mailing list (for the next 5 days), send a note to: wavepro-driver-developers@lists.sourceforge.net (in 5 days, you'll have to be subscribed to send a note) -Mike Mazarick
mazarick@bellsouth.net wrote:
It would be fine to say "vi is the development environment,
Actually, I'm using vim.
and we sprinkle the code with printk statements and take them out when the soup's done".
When using snd_printd() or snd_printdd(), one doesn't need to take them out afterwards. :)
1. Do you regularly use the "alsasound" kernel function during development so you can take the driver in and out of the kernel?
I regularly (un)load the modules that I'm changing. In most cases I don't use the script that came with my distribution because I don't want to (un)load all the other sound drivers, too.
3. Are there tools that are almost always used when writing a sound card driver like gdb, ddd, etc?
These debuggers don't work with kernel code.
4. Since it's easy to do, is an interface into the proc file system useful from the start?
Yes. Most drivers have some proc file that dumps the current register contents. It's always helpful to be able to check what your code did to the chip.
1. We've having difficulty getting the Altera PLD to load.
This code in uart_gl824_program_pld looks very suspicious: //YUCK: This stops us from actually doing it. if( uart_io_port != NULL ){ return(0); }
2. Should the 'load the Altera' function be part of the alsa driver, part of alsa firmware, or should we just load it up when the computer boots (not in alsa)?
Doing it in the driver is easiest (otherwise you would have to write another kernel module) and ensures that it's actually done before using the driver. HTH Clemens
On Jan 21, 2008 6:25 PM, <mazarick@bellsouth.net> wrote:
2. The GL card is powered from an Altera PLD (FPGA) (it has similar function as the Envy ICE chip once it's loaded). For the card to function at all, the Altera PLD has to be loaded when power is applied to the computer. Should the 'load the Altera' function be part of the alsa driver, part of alsa firmware, or should we just load it up when the computer boots (not in alsa)?
You could check how the wireless card drivers (e.g. ipw2200) install their firmware code during module loading. I think it's the most common instance of firmware loading, I would also investigate the kernel firmware subsystem to see how it works.
Just covering the things that are still missing... At Mon, 21 Jan 2008 20:25:37 +0000, mazarick@bellsouth.net wrote:
3. Are there tools that are almost always used when writing a sound card driver like gdb, ddd, etc?
Don't forget strace. It's quite useful to track down strange behavior or the driver.
4. Since it's easy to do, is an interface into the proc file system useful from the start? http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1493.htm
You can implement a proc write for debugging. It's useful for changing the register value on the fly. Takashi
participants (4)
-
Claudio Matsuoka -
Clemens Ladisch -
mazarick＠bellsouth.net -
Takashi Iwai