From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755373AbcANQVt (ORCPT ); Thu, 14 Jan 2016 11:21:49 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:34615 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753892AbcANQVr (ORCPT ); Thu, 14 Jan 2016 11:21:47 -0500 Date: Thu, 14 Jan 2016 16:21:42 +0000 From: Matt Fleming To: Sylvain Chouleur Cc: linux-efi@vger.kernel.org, Sylvain Chouleur , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner Subject: Re: [PATCH 2/2] efi: implement interruptible runtime services Message-ID: <20160114162142.GD3602@codeblueprint.co.uk> References: <1450434591-31104-1-git-send-email-sylvain.chouleur@gmail.com> <1450434591-31104-2-git-send-email-sylvain.chouleur@gmail.com> <20160106125846.GC2671@codeblueprint.co.uk> <20160108103837.GB2532@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 08 Jan, at 02:57:13PM, Sylvain Chouleur wrote: > > I understand, like I said above I'll modify efi_interruptible handlers to > call legacy ones in case of panic context. > I would like to avoid removing the panic part of this patch and take time > to clean it before merging the whole. OK, well at least split out the panic diddling into a separate patch so that we can discuss the merits of it separately to the other, less contentious changes. > > Kconfig is a last resort because it's a build-time decision and > > greatly limits the flexibility of the kernel. It becomes no longer > > possible to run a single kernel image with various CONFIG_* enabled on > > x86 hardware - you now need a special EFI_INTERRUPTIBLE build. > > > > Which apart from being a major headache for distributions in general > > is generally frowned upon for the x86 architecture. > > > > If there's any way at all of making this a runtime decision that would > > be much better. > > I think the best would be to bind this driver with the one which receives the > interrupts from CSE to write the variables. Then we would have a consistency > on the feature. > Does this seems ok for you? I think that'd be an improvement, yeah.