Date 3.10.2011 17:42, Takashi Iwai wrote:
At Mon, 03 Oct 2011 16:04:46 +0200, Jaroslav Kysela wrote:
Date 3.10.2011 14:27, Takashi Iwai wrote:
At Mon, 03 Oct 2011 14:01:00 +0200, David Henningsson wrote:
Hi Takashi etc,
- I think it would make sense to have a designated time and room for a
"future of HDA" discussion in Prague. We could e g discuss input jacks as kcontrols, and exposing routing to user space, as IIRC Mark Brown was suggestion earlier. What do you think?
Sure, we can hold a meeting spontaneously, as this would be for smaller group. The sound BoF isn't exactly scheduled at all yet. I don't know how many guys will be there, so I thought it can be managed spontaneously by announcing on the message board there or so.
I'll be there (LinuxCon), so you may count me in.
Good to hear!
To this topics: For some months, I play with an idea to move the whole HDA configuration stuff outside the kernel and leave in kernel just mandatory things like the HDA controller code and a library with functions for the user space code.
Because it's a bit nonsense to start with something totaly new when we have a good C codebase with hw descriptions. I looked around the net for a simple, small C compiler and it seems that TCC (www.tinycc.org) is ideal for this purpose.
I created own instruction 32/64-bit set (C optimized) and I'm now at the point that I can compile the HDA code to this instruction set with special TCC version and I have a simple disassembler to figure the compilation/linking issues.
The ELF loader and instruction parser is also quite complete. but a lot of work is missing especially to create the in-kernel library for all stuff which is required from the codec description code (kcontrol, procfs interface etc.). Also, the codec specific source code should not use some in-kernel things directly, but via macros or in-line helpers.
The end result should be "one universal kernel driver and firmware files describing the codecs". The possibility to compile the codec specific source code directly in the kernel should be retained and the source code between build-in driver codes and firmware codes should be shared.
I hope that you like this idea like me. All opinions are welcome. We may discuss this idea in Prague. I can post my work somewhere for further discussion or collaborative development.
As David already wrote, moving a big stuff into user-space is nice in one side. I fully agree, too. And, the techniques you described in the above sounds pretty interesting, makes me curious about the detailed implementation. But, it's a different question whether this would be accepted as the standard.
First off, the biggest concern in this approach is the extra step user need. In general, moving configuration to user-space from the device driver tends to fail. You might remember the attempt of em28xx TV-tuner driver, or such examples. It's mostly because the extra step and lost sync of code control from the kernel tree lead to more burden for users, even for distros.
I read the lwn artice about the em28xx driver and this is a bit different example.
Another big concern is that you'll run a native code in kernel-space. Such a support is unlikely welcome into the kernel tree, no matter how you say it must be safe.
Yes, it is for the linux kernel list discussion what the native means and what kind of userspace <-> kernel space interaction is allowed. For example, the BPF JIT landed to the current 3.x kernels.
_From the security perspective, the loading of the firmware files with 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