1 |
Anyhow, I would like to see alsa-drivers removed, but only with the |
2 |
condition that the in-kernel ALSA drivers work as expected. The bug I |
3 |
mentioned, if you reread it, you will notice that if there was no |
4 |
external alsa-driver, hda-intel would be marked broken as well, for |
5 |
some users. |
6 |
|
7 |
Just to make it short, in-kernel hda-intel works for some people, but |
8 |
it doesn't for others. The logical bug to be fixed is that the kernel |
9 |
guys (not our kernel guys) check what's going wrong in there. If that |
10 |
did happen, then your point of view wouldn't need any argumentation. |
11 |
|
12 |
What really has annoyed me is the fact that the external driver works, |
13 |
and I hope to see that not happen again. Unfortunately, that's not in |
14 |
my hands right now. |
15 |
|
16 |
If we are able to convince upstream maintainers about this, to report |
17 |
the bugs properly and to get them fixed as required, we could go ahead |
18 |
and remove alsa-drivers. Until that happens, seeing the current |
19 |
proofs, the best choice is "if it works don't fix it". |
20 |
|
21 |
On 3/28/07, Daniel Drake <dsd@g.o> wrote: |
22 |
> Ioannis Aslanidis wrote: |
23 |
> > Well, to be honest, I am neither supporter nor detractor. I think that |
24 |
> > it's upstream that should go and fix themselves. It's them who have |
25 |
> > caused all this. |
26 |
> |
27 |
> The bug you linked to is a natural effect of maintaining kernel drivers |
28 |
> outside of the kernel source tree. |
29 |
> |
30 |
> It is not the fault of the alsa-driver maintainers (either Gentoo or |
31 |
> upstream people who push tarballs), since they don't control the |
32 |
> in-kernel API's. |
33 |
> |
34 |
> It's not the kernels fault because the kernel does not claim to maintain |
35 |
> a stable internal API, and it actually readily claims the opposite. This |
36 |
> is not going to change. With reference to the problems an unstable |
37 |
> internal API causes, kernel people will give you one answer and one |
38 |
> answer only: get your code in the kernel. Problems like these simply do |
39 |
> not happen there. |
40 |
> |
41 |
> So, in this particular case, if the alsa-driver portage package did not |
42 |
> exist, the bug in question (plus a whole series of others in the same |
43 |
> class) simply will not ever occur. This is a good thing. |
44 |
> |
45 |
> > ALSA guys do not support in-kernel stuff. |
46 |
> |
47 |
> ALSA guys being upstream alsa-project.org people? That's not correct, |
48 |
> they are the people who put the code in the kernel. |
49 |
> |
50 |
> ALSA guys being downstream gentoo maintainers? That's true, since there |
51 |
> is a separate team who maintain the kernel. |
52 |
> |
53 |
> > Kernel guys do not support alsa stuff. |
54 |
> |
55 |
> Upstream kernel guys? No, they support alsa, actually most of the bugs |
56 |
> are handled by the alsa-project.org people who generally handle them |
57 |
> very well. |
58 |
> |
59 |
> Downstream kernel guys (i.e. Gentoo kernel herd)? No, we support the |
60 |
> sound subsystem and the ALSA drivers just like all other subsystems and |
61 |
> drivers in the kernel. |
62 |
> |
63 |
> Thanks, |
64 |
> Daniel |
65 |
> -- |
66 |
> gentoo-dev@g.o mailing list |
67 |
> |
68 |
> |
69 |
|
70 |
|
71 |
-- |
72 |
Ioannis Aslanidis |
73 |
|
74 |
<deathwing00[at]gentoo.org> 0xB9B11F4E |
75 |
-- |
76 |
gentoo-dev@g.o mailing list |