From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 994C613868D for ; Fri, 25 Jan 2013 19:57:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D26F721C04C; Fri, 25 Jan 2013 19:57:11 +0000 (UTC) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CFA08E057F for ; Fri, 25 Jan 2013 19:57:10 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so1159329iae.25 for ; Fri, 25 Jan 2013 11:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Kl5KuWqcDCTyXYgQw390kep+TSkguVrplCLfHWeLnFM=; b=0e4z5+pBdRNQoO3eWRWQIVC+5DfdifCe/kZydfeXCpgrUnL/c9pdYvW8g/9OB5od45 7TReT4MgvS6/NnQqxklMOfS1oZQdkF6iWcpUoC4ZsyxD3KvpHXytumr5sK87F4WOWvmh kAiqrqHbm03Oly4lTS4M4RLMbTsTvDQJlEChX/QajSVJfXjPxXeuhcu2rBhcADMHCkN7 ZPn97GS4nwYLQ1OMZk2uEiSGSHlWX2sXuZ6jMKKTKjC7p51uRq0TfoEpIIgS30RTVhw4 UGzAmlNT8oEEctm5a5kDnOg4IoMJ9xHQjIcRPi84Yy9wZLmUYnDbDI7yDzo2dHGyWEOq jHYQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.203.37 with SMTP id kn5mr4770479igc.47.1359143829860; Fri, 25 Jan 2013 11:57:09 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.30.231 with HTTP; Fri, 25 Jan 2013 11:57:09 -0800 (PST) In-Reply-To: <87zjzxm4do.fsf@ist.utl.pt> References: <874ni5nmtb.fsf@ist.utl.pt> <87zjzxm4do.fsf@ist.utl.pt> Date: Fri, 25 Jan 2013 14:57:09 -0500 X-Google-Sender-Auth: P6aW17HOVOJ7JbbgqFg1xgkdh3k Message-ID: Subject: Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: d66fc536-4cda-42d1-8372-97713021714b X-Archives-Hash: 3adaedaf02e4d9591e97c4a7044f2418 On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva 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