[alsa-devel] Future of the HDA driver

[Jaroslav Kysela]

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
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.