1 |
2014-11-10 12:37 GMT-02:00 Rich Freeman <rich0@g.o>: |
2 |
|
3 |
> On Mon, Nov 10, 2014 at 9:20 AM, Tanstaafl <tanstaafl@×××××××××××.org> |
4 |
> wrote: |
5 |
> > On 11/10/2014 8:21 AM, Francisco Ares <frares@×××××.com> wrote: |
6 |
> >> Checking the news (eselect news read), I see that an upgrade to udev-217 |
7 |
> >> might break firmware loading, so the news tagged |
8 |
> >> "2014-11-07-udev-upgrade" says that a kernel >= 3.7 should be |
9 |
> configured to: |
10 |
> >> |
11 |
> >> CONFIG_FW_LOADER_USER_HELPER=n |
12 |
> >> |
13 |
> >> Is it that simple? Trying a new kernel build using "menuconfig", it |
14 |
> >> says that CONFIG_FW_LOADER_USER_HELPER depends on CONFIG_FW_LOADER, and |
15 |
> >> this one depends on a huge list of other configuration elements. |
16 |
> >> |
17 |
> >> Any thoughts? |
18 |
> > |
19 |
> > Ueah... UGH... thanks Lennart/systemd devs for yet another thing to have |
20 |
> > to worry about... |
21 |
> > |
22 |
> |
23 |
> From the kernel config instructions (something not written by the systemd |
24 |
> devs): |
25 |
> This option enables / disables the invocation of user-helper |
26 |
> (e.g. udev) for loading firmware files as a fallback after the |
27 |
> direct file loading in kernel fails. The user-mode helper is |
28 |
> no longer required unless you have a special firmware file that |
29 |
> resides in a non-standard path. Moreover, the udev support has |
30 |
> been deprecated upstream. |
31 |
> |
32 |
> Announcing a feature as deprecated and later dropping it is hardly |
33 |
> controversial. You chose a distro that gives you a choice of things |
34 |
> like your udev implementation and your kernel implementation (or using |
35 |
> udev at all), and as a result you get to deal with the fact that some |
36 |
> versions of the one have constraints on how you use the other. If you |
37 |
> ran a distro like Ubuntu you wouldn't have to worry about any of this, |
38 |
> as you'd use the udev they gave you and the precompiled kernel they |
39 |
> gave you and the world's greatest desktop environment and you'd be |
40 |
> happy with it. Anybody who has run Gentoo for a long time knows that |
41 |
> from time to time some change comes along and you'll just have to deal |
42 |
> with it - you can't just ignore things like firmware-loading on Gentoo |
43 |
> the way you can with some other distros. |
44 |
> |
45 |
> Of course, nothing prevents anybody from creating a preconfigured |
46 |
> kernel for Gentoo. There is genkernel of course, though I think we |
47 |
> probably could do better. Most seem to be happy just managing their |
48 |
> own kernel configurations, and I think that is why nobody has bothered |
49 |
> to spend much time perfecting a canned kernel. |
50 |
> |
51 |
> Going back to the original question, yes - it is that simple. |
52 |
> Dependencies are just dependencies - you only have to worry about them |
53 |
> when you turn things ON. |
54 |
> |
55 |
> -- |
56 |
> Rich |
57 |
> |
58 |
> |
59 |
|
60 |
Ok, I will try. |
61 |
|
62 |
So, if I understood something, I will probably have to check this |
63 |
configuration entry every time I build a new kernel from now on, because |
64 |
"menuconfig" will probably set this on because of its dependencies, is this |
65 |
correct? |
66 |
|
67 |
Thanks! |
68 |
Francisco |