On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote:
> >>> On 27.09.12 at 20:06, Daniel Kiper <[email protected]> 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.
> > @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
> >
> > page = list_entry(pos, struct page, lru);
> > list_del(&page->lru);
> > - kimage_free_pages(page);
> > + (*kexec_ops.kimage_free_pages)(page);
>
> These constructs are generally better readable without the
> explicit yet redundant indirection:
>
> kexec_ops.kimage_free_pages(page);
I have done that in that way because during my work on memory hotplug
Andrew Morton aligned my patches to that syntax. However,
I do not insist on staying with it.
Daniel
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 <[email protected]> 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.