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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
