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: <20120719175649.GF8469@zod.bos.redhat.com>
Date:	Thu, 19 Jul 2012 13:56:50 -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 01:33:42PM -0400, Steven Rostedt wrote:
> 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'.

Distros aren't stationary things.  I mean, some of them certainly aim
for that goal, but userspace and kernels get upgraded all the time.  So
if this distro-Kconfig file is provided by some package _other_ than the
kernel the distros are going to have a bit of a hassle keeping track of
it.

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

I'm not quite following what you mean in the yum update case, sorry.

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

Upgraded the kernel within the confines of that distro, right?  So you
go back to what was already installed and working.  You don't go back
arbitrarily far just to see what happens.  I would think a reasonably
crafted distro config would work in those scenarios.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ