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. :)
- 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.
- 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.
- 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.
- 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); }
- 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