No subject

the interpreted bytecode can be handled in exactly same way as the
native kernel modules. If someone creates a broken native kernel module,
it has the same impact as a broken interpreted code, but the interpreter
can detect the failure (when the interpreter is properly written) and
terminate the bytecode processing.

> Lastly, there is no much need of specific "firmware" nowadays in most
> cases.  The most of the parser code can be shared by each codec, and
> the difference between codec drivers would become minimum in the end.
> If so, there is no need for loading some codes dynamically.  You can
> simply use a module as of now.

I meant to move all codec (patch/quirk) codes outside the kernel space.
Ideally, only the HDA PCM interface and basic verb I/O should be in the
kernel, all other things (PCM assignment, kcontrol creation and
handling, unsolicited event handling, HDMI handling etc.) might be moved
outside. Basically, only hda_intel.c and some portions of hda_codec.c
should be in the kernel.

> Anyway, the technique sounds interesting, as mentioned, so let's keep
> discussions.

I created a wiki page
http://www.alsa-project.org/main/index.php/HDA_UserSpace which tries to
gather all major information for further discussions. I will release
some code in few days.

					Jaroslav

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