At Tue, 15 Jan 2008 17:20:00 -0200, Claudio Matsuoka wrote:
On Jan 15, 2008 4:36 PM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
when I looked today through the files of the snd-hda-intel module, I was a bit shocked by this complex amount of code (patch_realtek.c for example). I would think about splitting up the code in a way each chipset gets its own .c file - which will make debugging, patching or editing a lot easier IMO, and for second people can then comment on just their specific chipset in config.
What do you think about this?
One interesting development for hda drivers would be to keep the basic infrastructure for each codec in the driver, and configure them from userspace. That would remove all quirks and special cases from the kernel, and allow easier update for users without the need of deploying a new kernel (or new ALSA), just updating the userspace tool.
Yes, that's my favarite option.
It's a good question whether the setup should be the codec (driver) dependent or generic. I tend to believe that we'll need some codec-specific workarounds, at least, to keep the same level of the driver support as now.
In my earler development, I implemented some byte-code implementer in the driver so that it can be handled in a generic way. The current codec specific implementation is interpreted to a byte-code in the user-space tool, and it runs on the driver. Of course, this method adds an interpreter to the driver, and I'm also not sure whether this method is optimal.
In theory, we can create a good generic parser with minimal hints. The problem of a generic parser is that it's often fragile to the code changes and the breakage isn't visible in a straight way. The hw-specific implementation is, OTOH, awfully ad hoc, difficult to extend to other hardwares, but it's simple and solid.
Takashi