[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121106091217.4a5240f0@pyramind.ukuu.org.uk>
Date: Tue, 6 Nov 2012 09:12:17 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Pavel Machek <pavel@....cz>,
Chris Friesen <chris.friesen@...band.com>,
Eric Paris <eparis@...isplace.org>,
Jiri Kosina <jkosina@...e.cz>, Oliver Neukum <oneukum@...e.de>,
Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support
On Tue, 6 Nov 2012 03:53:52 +0000
Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
>
> > For automated installs you don't have to satisfy me. Feel free to
> > deliver a lousy solution to your users. Just don't use your arbitrary
> > design decisions to justify your kernel patches.
>
> My kernel patches are justified by genuine user requirements.
So are lots of patches tht don't go in because they are too ugly or too
invasive or two special case for mainstream.
There are two discussions here
- is it worth Red Hat doing - that's up to Red Hat's business managers
- is it worth merging into the kernel - that's not
The capability bit is small and clean the rest of it is beginning to look
far too ugly for upstream right now. Not to say it might not end up small
and clean in the end.
Alan
--
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