[alsa-devel] Future of the HDA driver
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?
2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the door, I might have some time to contribute to the HDA driver...at least if not a lot of urgent stuff comes up, and up to the 3.2 merge window or so. (Any idea how far away that would be?) Do you think it would make sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move snd_hda_parse_pin_defcfg there, then add more functions as discovered to be useful to more than one autoparser?
3) One thing that has been annoyed me lately is the moving of hp out or speaker out to line out, which IMO leads to somewhat messy code. Seen in retrospect of course, don't you think it would make more sense to do let line_out_pins be "line out" only, and add one more variable primary_out that would be initialized as:
primary_out_pins = line_outs ? &line_out_pins : (speaker_outs ? &speaker_out_pins : (hp_outs ? &hp_out_pins : NULL))
..and then you could do something like:
#define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == &(_auto)->hp_out_pins)
Redoing that will probably require careful reading to avoid regressions though...
On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:
- 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?
There's already an audio meeting of some kind scheduled I believe, is there any need to have another discussion specifically for HDA?
On 10/03/2011 02:12 PM, Mark Brown wrote:
On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:
- 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?
There's already an audio meeting of some kind scheduled I believe, is there any need to have another discussion specifically for HDA?
Yes, I believe so - I think the other meeting was more about GStreamer integration with lower layers? At least that's what I think the GStreamer people want to discuss. :-)
At Mon, 03 Oct 2011 14:14:35 +0200, David Henningsson wrote:
On 10/03/2011 02:12 PM, Mark Brown wrote:
On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:
- 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?
There's already an audio meeting of some kind scheduled I believe, is there any need to have another discussion specifically for HDA?
Yes, I believe so - I think the other meeting was more about GStreamer integration with lower layers? At least that's what I think the GStreamer people want to discuss. :-)
Well, we may hold a generic sound meeting including ASoC. This is what I originally thought of. The topic HD-audio can be sorted there, too, but I believe this is way too specific and better to be a separate small meeting, as David suggested.
In addition, Gstreamer guys want a BoF, and this would be a different topic, concentrated on gstreamer (although HD-audio is greatly involved). I haven't heard of the new about gstreamer BoF since the last announcement, though. I'm going to ping.
thanks,
Takashi
On Mon, Oct 03, 2011 at 02:14:35PM +0200, David Henningsson wrote:
On 10/03/2011 02:12 PM, Mark Brown wrote:
There's already an audio meeting of some kind scheduled I believe, is there any need to have another discussion specifically for HDA?
Yes, I believe so - I think the other meeting was more about GStreamer integration with lower layers? At least that's what I think the GStreamer people want to discuss. :-)
My understanding had been that we'd just got put on their schedule for some reason, I've certainly not seen any discussions with them.
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.
- With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
door, I might have some time to contribute to the HDA driver...at least if not a lot of urgent stuff comes up, and up to the 3.2 merge window or so. (Any idea how far away that would be?) Do you think it would make sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move snd_hda_parse_pin_defcfg there, then add more functions as discovered to be useful to more than one autoparser?
The merge window for 3.2 is almost closed now, as 3.1 will come out today or tomorrow, I suppose. Such a big change as you suggested in the above is a 3.3-material, I suppose.
The unification of parsers is a longterm goal. My plan is to reduce the rest of Realtek-quirk codes as much as possible in 3.3, try to clean up / implement the auto-parser for AD codecs, and slowly starting to the unified parser by moving the pieces to the core hd-audio code from codec-specific codes.
- One thing that has been annoyed me lately is the moving of hp out or
speaker out to line out, which IMO leads to somewhat messy code. Seen in retrospect of course, don't you think it would make more sense to do let line_out_pins be "line out" only, and add one more variable primary_out that would be initialized as:
primary_out_pins = line_outs ? &line_out_pins : (speaker_outs ? &speaker_out_pins : (hp_outs ? &hp_out_pins : NULL))
..and then you could do something like:
#define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == &(_auto)->hp_out_pins)
Redoing that will probably require careful reading to avoid regressions though...
Yeah, the current code is still messy although you cleaned up a lot. This needs revisited.
thanks,
Takashi
On 10/03/2011 02:27 PM, 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.
Sorting something out on-site will probably work as well, but I was just thinking that a pre-scheduled meeting is less likely to be forgotten or missed.
- With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
door, I might have some time to contribute to the HDA driver...at least if not a lot of urgent stuff comes up, and up to the 3.2 merge window or so. (Any idea how far away that would be?) Do you think it would make sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move snd_hda_parse_pin_defcfg there, then add more functions as discovered to be useful to more than one autoparser?
The merge window for 3.2 is almost closed now, as 3.1 will come out today or tomorrow, I suppose. Such a big change as you suggested in the above is a 3.3-material, I suppose.
Oh, I always seem to have bad timing :-(
But maybe I can make a 3.2 patch today or tomorrow to make naming of the input jacks a little more consistent, right now it's a little different between Realtek and Sigmatel/IDT parsers, e g.
The unification of parsers is a longterm goal. My plan is to reduce the rest of Realtek-quirk codes as much as possible in 3.3, try to clean up / implement the auto-parser for AD codecs, and slowly starting to the unified parser by moving the pieces to the core hd-audio code from codec-specific codes.
Hmm, maybe better to move things to a more generic auto-parser first, then the AD auto-parser could be more easily implemented. But I trust your judgement on the matter :-)
- One thing that has been annoyed me lately is the moving of hp out or
speaker out to line out, which IMO leads to somewhat messy code. Seen in retrospect of course, don't you think it would make more sense to do let line_out_pins be "line out" only, and add one more variable primary_out that would be initialized as:
primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ? &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
..and then you could do something like:
#define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == &(_auto)->hp_out_pins)
Redoing that will probably require careful reading to avoid regressions though...
Yeah, the current code is still messy although you cleaned up a lot. This needs revisited.
Heh, thanks for the credit, although my contributions are fairly small compared to yours :-)
At Mon, 03 Oct 2011 15:14:47 +0200, David Henningsson wrote:
On 10/03/2011 02:27 PM, 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.
Sorting something out on-site will probably work as well, but I was just thinking that a pre-scheduled meeting is less likely to be forgotten or missed.
It's fine for me to have a fixed schedule, too.
- With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
door, I might have some time to contribute to the HDA driver...at least if not a lot of urgent stuff comes up, and up to the 3.2 merge window or so. (Any idea how far away that would be?) Do you think it would make sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move snd_hda_parse_pin_defcfg there, then add more functions as discovered to be useful to more than one autoparser?
The merge window for 3.2 is almost closed now, as 3.1 will come out today or tomorrow, I suppose. Such a big change as you suggested in the above is a 3.3-material, I suppose.
Oh, I always seem to have bad timing :-(
But maybe I can make a 3.2 patch today or tomorrow to make naming of the input jacks a little more consistent, right now it's a little different between Realtek and Sigmatel/IDT parsers, e g.
Yes, such a small fix is welcome, of course. I merged your patch now.
The unification of parsers is a longterm goal. My plan is to reduce the rest of Realtek-quirk codes as much as possible in 3.3, try to clean up / implement the auto-parser for AD codecs, and slowly starting to the unified parser by moving the pieces to the core hd-audio code from codec-specific codes.
Hmm, maybe better to move things to a more generic auto-parser first, then the AD auto-parser could be more easily implemented. But I trust your judgement on the matter :-)
This can be started in parallel. I thought of starting AD-codec support because it has already the parser for AD1988, but not for others. But, it can be judged later dynamically, whether to proceed the generic code more ahead or first finish the AD-codec parser.
- One thing that has been annoyed me lately is the moving of hp out or
speaker out to line out, which IMO leads to somewhat messy code. Seen in retrospect of course, don't you think it would make more sense to do let line_out_pins be "line out" only, and add one more variable primary_out that would be initialized as:
primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ? &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
..and then you could do something like:
#define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == &(_auto)->hp_out_pins)
Redoing that will probably require careful reading to avoid regressions though...
Yeah, the current code is still messy although you cleaned up a lot. This needs revisited.
Heh, thanks for the credit, although my contributions are fairly small compared to yours :-)
I expect more codes will come up from you in near future ;)
thanks,
Takashi
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.
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.
Jaroslav
On 10/03/2011 04:04 PM, 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.
Ok, looking forward to meeting you!
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.
In general I like the idea of moving the codec stuff to userspace, because that opens up for post-release updates where distributions can fix things without having to release an entire kernel.
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.
Hmm. I'm not a kernel veteran, but I wonder how well received this will be in the wider community. I'm a little sceptic to the additional step this will be when it comes to bootstrapping a Linux system, or that you need to fix a bug in the userspace code. An extra dependency on a compiler. Debugging the interpreter and all that, which must also be reasonably easy to understand and maintain. Having a low entrance for new contributors is important, and I'm a little worried that this will be worse with the suggested implementation.
Also, what about code size here, will the sum of firmware + kernel code exceed the current kernel code size?
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.
Well, having a well working HDA driver for both current and future codecs and controllers is very important and from time to time I'll be able to contribute moderately. So whatever is decided upon will be my focus of contributions personally.
Also, what do you think is the time frame for having something like this in mainline kernel?
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.
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.
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.
Anyway, the technique sounds interesting, as mentioned, so let's keep discussions.
thanks,
Takashi
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
On 10/04/2011 10:56 AM, Jaroslav Kysela wrote:
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.
I also read it, and it makes me concerned about something. If/when this solution is deployed, do we risk that codec vendors - that now submit kernel patches - instead start giving out precompiled firmware files? If that would happen, it would be a great loss IMO.
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.
IIRC, module loading can be disabled and is used by some security people to harden the kernel. Do they now lose that possibility of hardening, or are you suggesting they disable firmware file loading as well? Or would that disable the audio function completely?
At Mon, 03 Oct 2011 14:27:34 +0200, Takashi Iwai wrote:
- With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
door, I might have some time to contribute to the HDA driver...at least if not a lot of urgent stuff comes up, and up to the 3.2 merge window or so. (Any idea how far away that would be?) Do you think it would make sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move snd_hda_parse_pin_defcfg there, then add more functions as discovered to be useful to more than one autoparser?
The merge window for 3.2 is almost closed now, as 3.1 will come out today or tomorrow, I suppose. Such a big change as you suggested in the above is a 3.3-material, I suppose.
Looks like rc9 might be released before final, so we have still a little bit of time left. But I don't want too drastic change at this moment, at least, for 3.2-merge.
Of course, I can keep any more radical changes in a devel branch and merge back later once after 3.2 merge is closed. That's why there are master and for-next branches in sound git tree. So, don't worry about the schedule. The patches won't be lost.
Takashi
participants (4)
-
David Henningsson -
Jaroslav Kysela -
Mark Brown -
Takashi Iwai