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: <1342719222.12353.58.camel@gandalf.stny.rr.com>
Date:	Thu, 19 Jul 2012 13:33:42 -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 13:19 -0400, Josh Boyer wrote:

> > 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.
> 
> How is the above not telling the kernel what it needs?  I'm confused how
> the location of such a file makes it's functionality and usefulness
> differ...  Quite possible I missed what you meant originally, but it
> sounds like we're talking about the same thing?

The point is, the user wont have to think "What distro am I running? and
what version am I running?". I don't even know what version of the disto
I'm currently running (Debian testing).

The point is, the current running distro supplies what is needed from
the kernel in order to work properly. The user does not need to 'select'
it. They would only have to select a 'add my distro min configs'.

A developer working with a user could just say, "select disto config"
without needing to know what distro the user has.

What happens if someone does a yum update, and the kernel requirement
changes slightly. The yum update should update
this /usr/share/Linux/Kconfig. But it's still set at Fedora X. The
kernel can not be updated for these slight changes.

> 
> Also, I'm not very convinced the 99% are going to be wanting to install
> shiny new versions of a distro with a kernel older than what the distro
> ships with.  I could be very wrong, but it seems like in-general the
> whole premise of this RFC was geared towards using new kernels on
> distros.

There are times when the update breaks something. A user may backport to
an older kernel where their Gizmo worked. I've done this to get webcams
working. I know I'm not the 99%, but the rational for my operation was a
99% thing to do: Crap, I upgraded my kernel and now my webcam doesn't
work. Oh well, download an older version and boot that one.

> 
> > 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.
> 
> kconfig already spits out warnings for symbols being selected that
> don't exist.

We can make these even bigger :-)   Add lots of stars (*) around them!

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