1 |
On 2013-01-25, Rich Freeman wrote: |
2 |
|
3 |
> On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva <nunojsilva@×××××××.pt> wrote: |
4 |
>> |
5 |
>> Sorry, what's the difference between cheching =y and =m? I thought those |
6 |
>> were both part of the kernel config... |
7 |
> |
8 |
> I'm talking about /proc/config.gz, which only reflects .config at the |
9 |
> time that the kernel was built. So, build with config=n, then set |
10 |
> config=m and install the modules but don't replace the kernel. Now |
11 |
> /proc/config.gz still says n, but the module is there and works fine. |
12 |
> And this is in fact the easiest way to add a module for something that |
13 |
> you didn't realize you needed at kernel build time - you can do this |
14 |
> on a running system. |
15 |
> |
16 |
>> |
17 |
>>> You can also check /usr/src/linux/.config, but the sources might not |
18 |
>>> correspond to the running kernel, or the kernel on the next reboot, or |
19 |
>>> whatever. |
20 |
>> |
21 |
>> Ok, what do these checks do right now? I thought that they were checking |
22 |
>> .config... |
23 |
> |
24 |
> I dunno. I wasn't talking about how the current config checks work. |
25 |
> The question was whether it was possible to determine how the kernel |
26 |
> was configured - I was answering in general. |
27 |
|
28 |
I am almost sure the current check does *not* use config.gz but |
29 |
/usr/src/linux/.config. At least, I've not had config.gz enabled for a |
30 |
long time, and I've always seen the checks working. In fact, I think the |
31 |
checks print something along the lines of "looking for kernel source |
32 |
under /usr/src/linux... found config for linux-...". |
33 |
|
34 |
>> So you're saying that it's perfectly OK to check for =y or =n, but that |
35 |
>> it's somehow more difficult to check for =m? |
36 |
> |
37 |
> My previous paragraph was referring to checking config.gz - and that |
38 |
> is unreliable for modules. /usr/src/linux/.config is unreliable for |
39 |
> the reason I stated in the next paragraph - it doesn't necessarily |
40 |
> reflect the running kernel. |
41 |
|
42 |
Not only for modules, config.gz may not even be available, while |
43 |
/usr/src/linux/.config is reliable, as it should exist, and, when you're |
44 |
compiling, you're typically compiling for what is going to be your main |
45 |
kernel, the one under /usr/src/linux, which, to have been built, must |
46 |
have a .config, an. |
47 |
|
48 |
And you do not want to check against the running kernel, you want to |
49 |
check against the currently selected kernel. Checking /proc/config.gz |
50 |
would lead to issues when you're in middle of a kernel update and |
51 |
rebuilding modules before reboot. |
52 |
|
53 |
>> This won't even solve the issue, even if some people may actually prefer |
54 |
>> a pre-built kernel. |
55 |
> |
56 |
> Depends on the issue. There isn't just one issue under discussion in |
57 |
> this thread. A fairly bulletproof kernel solves a lot of issues in |
58 |
> general as it can have newbie-safe defaults (like just about anything |
59 |
> in any config check). There is a reason that most distros don't need |
60 |
> config checks. |
61 |
|
62 |
Well, we could also get rid of issues with clashing USE flags by getting |
63 |
rid of USE flags and offering monolithic binary packages with almost |
64 |
every compatible feature enabled by default. |
65 |
|
66 |
And newbie-safe, I've had far too many systems where your usual binary |
67 |
distro "newbie-safe" kernel fails and the first thing I need to do even |
68 |
with binary distros is to build my own kernel to get something that |
69 |
actually boots with no issues. |
70 |
|
71 |
>> But, definitely, fatal checks should not be a default, there are way too |
72 |
>> many scenarios. |
73 |
> |
74 |
> Yup - just trying to point out some of the perils. As I said there |
75 |
> are lots of 80% solutions. |
76 |
|
77 |
|
78 |
-- |
79 |
Nuno Silva (aka njsg) |
80 |
http://njsg.sdf-eu.org/ |