From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V1 1/2] Xen acpi memory hotplug driver
Date: Tue, 18 Dec 2012 10:47:37 -0500 [thread overview]
Message-ID: <20121218154737.GB13450@phenom.dumpdata.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353AD822@SHSMSX101.ccr.corp.intel.com>
> >>>> Not only inform firmware.
> >>>> Hotplug notify callback will invoke acpi_bus_add -> ... ->
> >>>> implicitly invoke drv->ops.add method to add the hotadded memory
> >>>> device.
> >>>
> >>> Gotcha.
> >>
> >> ? So it will lose the notification and no way to add the new memory
> >> device in the future.
> >>
> >> Xen memory hotplug logic consist of 2 parts:
> >> 1) driver logic (.add/.remove etc)
> >> 2) notification install/callback logic
> >> If you want to use 'xen_stub driver + .add/.remove ops', then
> >> notification install/callback logic would implement with xen_stub
> >> driver (means in build-in part, otherwise it would lose notification
> >> when the ops unload) --> but that would make xen_stub in big build-in
> >> size.
> >
> > How about
> > * build-in part: xen_stub driver (stub .add to record what matched
> > cpu devices) + notification install/callback;
> > * module part: .add/.remove ops;
> > w/ it, native driver has no chance to load and no hotplug event lose,
> > and approximately 1/3 code is build-in and 2/3 are module.
> >
> > I think it will work but I'm not quite sure, at least we can have a
> > try/test?
> >
> > Thanks,
> > Jinsong
> >
>
> Thoughts? If you think it's OK, I will update later.
Pls try. I am just thinking that the less we of code that has to be built-in - the
better.
>
> Thanks,
> Jinsong
prev parent reply other threads:[~2012-12-18 15:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 11:45 [PATCH V1 1/2] Xen acpi memory hotplug driver Liu, Jinsong
2012-11-28 19:26 ` Konrad Rzeszutek Wilk
2012-11-30 3:08 ` Liu, Jinsong
2012-12-05 17:43 ` Konrad Rzeszutek Wilk
2012-12-06 4:27 ` Liu, Jinsong
2012-12-07 14:05 ` Konrad Rzeszutek Wilk
2012-12-12 17:53 ` Liu, Jinsong
2012-12-14 13:05 ` Liu, Jinsong
2012-12-18 13:15 ` Liu, Jinsong
2012-12-18 15:47 ` Konrad Rzeszutek Wilk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121218154737.GB13450@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=jinsong.liu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.