On 2013-01-25, Rich Freeman wrote: > On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva <[email protected]> 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.
I am almost sure the current check does *not* use config.gz but /usr/src/linux/.config. At least, I've not had config.gz enabled for a long time, and I've always seen the checks working. In fact, I think the checks print something along the lines of "looking for kernel source under /usr/src/linux... found config for linux-...". >> 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. Not only for modules, config.gz may not even be available, while /usr/src/linux/.config is reliable, as it should exist, and, when you're compiling, you're typically compiling for what is going to be your main kernel, the one under /usr/src/linux, which, to have been built, must have a .config, an. And you do not want to check against the running kernel, you want to check against the currently selected kernel. Checking /proc/config.gz would lead to issues when you're in middle of a kernel update and rebuilding modules before reboot. >> 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. Well, we could also get rid of issues with clashing USE flags by getting rid of USE flags and offering monolithic binary packages with almost every compatible feature enabled by default. And newbie-safe, I've had far too many systems where your usual binary distro "newbie-safe" kernel fails and the first thing I need to do even with binary distros is to build my own kernel to get something that actually boots with no issues. >> 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. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
