On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva <nunojsi...@ist.utl.pt> wrote: > > Sorry, what's the difference between cheching =y and =m? I thought those > were both part of the kernel config...
I'm talking about /proc/config.gz, which only reflects .config at the time that the kernel was built. So, build with config=n, then set config=m and install the modules but don't replace the kernel. Now /proc/config.gz still says n, but the module is there and works fine. And this is in fact the easiest way to add a module for something that you didn't realize you needed at kernel build time - you can do this on a running system. > >> You can also check /usr/src/linux/.config, but the sources might not >> correspond to the running kernel, or the kernel on the next reboot, or >> whatever. > > Ok, what do these checks do right now? I thought that they were checking > .config... I dunno. I wasn't talking about how the current config checks work. The question was whether it was possible to determine how the kernel was configured - I was answering in general. > > So you're saying that it's perfectly OK to check for =y or =n, but that > it's somehow more difficult to check for =m? My previous paragraph was referring to checking config.gz - and that is unreliable for modules. /usr/src/linux/.config is unreliable for the reason I stated in the next paragraph - it doesn't necessarily reflect the running kernel. > This won't even solve the issue, even if some people may actually prefer > a pre-built kernel. Depends on the issue. There isn't just one issue under discussion in this thread. A fairly bulletproof kernel solves a lot of issues in general as it can have newbie-safe defaults (like just about anything in any config check). There is a reason that most distros don't need config checks. > But, definitely, fatal checks should not be a default, there are way too > many scenarios. Yup - just trying to point out some of the perils. As I said there are lots of 80% solutions. Rich
