[alsa-devel] Splitting up the HDA-INTEL modules

[Takashi Iwai]

At Tue, 15 Jan 2008 17:20:00 -0200,
Claudio Matsuoka wrote:
> 
> On Jan 15, 2008 4:36 PM, Marco Schuster <marco at 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