[alsa-devel] hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[Jaroslav Kysela]

On Tue, 27 Jul 2010, Takashi Iwai wrote:

>>> Meanwhile, the deployment of OF can be helpful if we move the whole
>>> parser stuff to the user-space and push the parsed/compiled tree info
>>> into the kernel (i.e. "firmware").  In such a case, OF representation
>>> can be more flexible; and the kernel has already the infrastructure.
>>
>> So move half of the kernel code into userspace? Are you suggesting that
>> user-space gets a NID-tree, like in the codec-proc file, and returns
>> back init verbs, controls, etc?
>
> Yes.

I thought about the user space parsing, but I would see rather a simple 
limited special purpose bytecode interpreter in the HDA driver in the 
first state and an one-shot compiler. The bytecode can be eighter static 
(read from a firmware file using a lookup scheme based on SSIDs, BIOS pin 
setups etc.) and later, we may eventually create a complicated user space 
solution (bytecode generator).

Note that for handling unsolicited events, the description of behaviour 
(may be dynamic - based on actual nid state) should be available. The 
bytecode interpreter solution is ideal for both  static and dynamic 
behaviour description. Ideally, everything in patch_* files should be 
rewritten to use the bytecode interpreter (including auto sections).

If we design a special high-level language and a compiler generating the 
bytecode for the driver, we can describe hw <-> ALSA mapping on fewer 
lines and also we can drastically reduce the possibility to introduce an 
error like in C.

 				Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.