linux-kernel - Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec

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] [day] [month] [year] [list]

Message-ID: <1349443636.20946.96.camel@zakaz.uk.xensource.com>
Date:	Fri, 5 Oct 2012 14:27:16 +0100
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Daniel Kiper <daniel.kiper@...cle.com>
CC:	Jan Beulich <JBeulich@...e.com>,
	Andrew Cooper <Andrew.Cooper3@...rix.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	xen-devel <xen-devel@...ts.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct

On Mon, 2012-10-01 at 12:36 +0100, Daniel Kiper wrote:
> On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote:
> > >>> On 27.09.12 at 20:06, Daniel Kiper <daniel.kiper@...cle.com> wrote:
> > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> > > not use default functions or require some changes in behavior of kexec/kdump
> > > generic code. To cope with that problem kexec_ops struct was introduced.
> > > It allows a developer to replace all or some functions and control some
> > > functionality of kexec/kdump generic code.
> >
> > I'm not convinced that doing this at the architecture independent
> > layer is really necessary/desirable. Nevertheless, if that's the right
> > place, then everything else looks good to me, except for a
> > cosmetic thing:
> 
> I do not like this patch, too. However, this is the simplest
> solution. If you do not do that in that way then you must
> duplicate most of kernel/kexec.c functionality in architecture
> depndent files.

It would have been a good idea to CC the maintainer of those files
directly with at least this patch if not the whole series.

If they don't like this approach then there not much point in doing a
thorough reviewing of the other 10 patches I don't think, since I would
expect they will be required to change pretty substantially under those
circumstances.

Ian.


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