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@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.