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]

Date:	Thu, 19 Jul 2012 12:08:08 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Josh Boyer <jwboyer@...hat.com>
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, 2012-07-19 at 11:45 -0400, Josh Boyer wrote:
> 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.

Then we'll have a list of options in each kernel:

 Fedora 16
 Fedora 17
 Fedora 18
 [...]
 Debian x
 Debian x+1
 Debian x+2
 [...]
 Ubuntu y
 Ubuntu y+1
 [...]

What about older kernels? Say you installed Fedora 18 with an older
kernel that doesn't know what to select? Having the distro tell the
kernel what it needs seems to me the easiest for the 99% case.

Also, if something isn't supported by the older kernel, it would warn
the user about it. That way the user can be told that their older kernel
won't work with this version of the distro. And there wont be as many
surprises. If the user is told "your init wont work with this kernel"
before they compile it, then they shouldn't complain if they decide to
install this older kernel and their box doesn't boot.

-- Steve


--
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/