[alsa-devel] Future of the HDA driver
perex at perex.cz
Tue Oct 4 10:56:13 CEST 2011
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,
>>>> 1) 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
> 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.
More information about the Alsa-devel