Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933387AbbHDLlU (ORCPT ); Tue, 4 Aug 2015 07:41:20 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:49565 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932678AbbHDLlS (ORCPT ); Tue, 4 Aug 2015 07:41:18 -0400 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: "'Eric W. Biederman'" CC: Vivek Goyal , Andrew Morton , "linux-mips@linux-mips.org" , Baoquan He , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "HATAYAMA Daisuke" , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= , Daniel Walker , "Ingo Molnar" Subject: RE: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes Thread-Topic: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes Thread-Index: AQHQzgsGDND7njYftUe3fB3L5gctF537r/GQ Date: Tue, 4 Aug 2015 11:41:14 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454926993@GSjpTKYDCembx31.service.hitachi.net> References: <20150724011615.6834.79628.stgit@softrs> <55BF4B1F.9000602@hitachi.com> <877fpcfi2j.fsf@x220.int.ebiederm.org> In-Reply-To: <877fpcfi2j.fsf@x220.int.ebiederm.org> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.220.34] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t74BfXLg032249 Content-Length: 1159 Lines: 28 Hello, Thanks for the reply. > From: Eric W. Biederman [mailto:ebiederm@xmission.com] [...] > A specific hook for a very specific purpose when there is no other way > we can consider. So, is kmsg_dump like feature admissible? > If you don't have something that generalises well into a general purpose > operation that it makes sense for everyone to call you can always use > the world's largest aka you can run code before the new kernel starts > that is loaded with kexec_load. One of our purposes, notifying "I'm dying", would be achieved by purgatory code provided by kexec command as I stated before. Since the way of the notification will differ from each vendor, I think we need to modify the purgatory codes pluggable. Also, I think we need some parameter passing mechanism to the purgatory code. For example, passing the panic message via boot parameter to save it to SEL. Although I'm not sure we can do that (I've not investigated well yet). Is that acceptable? Regards, Kawai ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?