linux-kernel - Re: [RFC] Simplifying kernel configuration for distro issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120719154521.GC8469@zod.bos.redhat.com>
Date:	Thu, 19 Jul 2012 11:45:21 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
	Debian Kernel Team <debian-kernel@...ts.debian.org>,
	OpenSUSE Kernel Team <opensuse-kernel@...nsuse.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Fedora Kernel Team <kernel-team@...oraproject.org>
Subject: Re: [RFC] Simplifying kernel configuration for distro issues

On Thu, Jul 19, 2012 at 11:26:18AM -0400, Steven Rostedt wrote:
> On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:
> > 
> > The *two* requirements (and they're really the same theme) I
> > personally think we should have for this are
> > 
> >  -  I think every single "select" for these things should come with a
> > comment about what it is about and why the distro needs it (to show
> > there was some thought involved and not just a blind "took it from the
> > distro config")
> 
> What about expanding on Alan's idea. I'm guessing that 99% of the users
> build the kernel for the box that they are running. If this is the case,
> perhaps we can get the distros to add a:
> 
>   /usr/share/Linux/Kconfig
> 
> And this Kconfig would have something like:
> 
> bool "Distro X config"
>  select A
>  select B
>  select C
>  [...]
> 
> Perhaps with a comment for each select. Or have the comments in the help
> section.
> 
> Then have the kernel kbuild system check if this file exists and include
> it.
> 
> Of course the kbuild system would need to verify that the selects exist,
> and perhaps warn if they do not. But the nice thing about this is that
> you would get the minconfig for the system you are running. When the
> system is updated to a new version, the minconfig would be updated too.
> The list of selects would not have to live in the kernel, nor would the
> kernel need to maintain the list for N+1 different distributions.

Is there a reason you don't want distro maintainers to maintain these
files in the upstream git tree?  (You said "the kernel need to
maintain", but I would expect the distro maintainers to be doing that
work.)

I think it would actually be beneficial to maintain them upstream
instead of in distro kernel packaging.  You'd be able to track the
history of changes with git.  You would see for a given kernel
version what options are set for each distro (e.g. F17 can support
NEW_FOO_THING but F16 userspace can't so it doesn't select that).
Perhaps most importantly, it provides a consolidated view of what
options various distros are setting and allows the distro maintainers to
easily do comparisons.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/