On Friday, March 04, 2011, Shriram Rajagopalan wrote:
> On Mon, Feb 28, 2011 at 3:06 AM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Fri, 25 Feb 2011, Rafael J. Wysocki wrote:
> >> On Friday, February 25, 2011, Stefano Stabellini wrote:
> >> > On Thu, 24 Feb 2011, Rafael J. Wysocki wrote:
> >> > > > I believe it only "[PATCH 3/3] PM: pm.h - Add comments about Xen
> >> > > > save/restore/chkpt use case"
> >> > > >
> >> > > > (http://marc.info/?i=1298157158-5421-4-git-send-email-rshriram@xxxxxxxxx)
> >> > >
> >> > > This particular one should go in _after_ the functional patches.
> >> > >
> >> > > > I or Stefano (these patches are against Ian's tree which is againsts
> >> > > > Stefano's
> >> > > > tree) can take the other patches and stick Pavel's Ack, Rafeal's
> >> > > > Ack, Ian's Ack
> >> > > > on them and also my Signed-off for the Xen bits.
> >> > > >
> >> > > > I think that would work?
> >> > >
> >> > > In fact, I think it's better if all patches go through the Xen tree.
> >> > >
> >> >
> >> > I don't mind taking them but if they have to go after your
> >> > suspend-2.6/linux-next tree this would introduce a new dependency in the
> >> > branch I am preparing for linux-next myself.
> >> >
> >> > Should I pull your suspend-2.6/linux-next tree into my linux-next branch?
> >> > Considering that this could create conflicts in linux-next if you
> >> > force-push your tree with some new changes and I don't update my version
> >> > of it, maybe it is better if I pull only a reduced version of it with
> >> > just the strict dependencies?
> >>
> >> It's not that simple, I think you'd need to pull my entire linux-next
> >> branch
> >> because of the dependencies between commits in there.
> >>
> >> Alternatively, I can take the entire $subject patchset.
> >>
> >> Still, I'd like the discussion to settle before anyway.
> >
> There has been no further discussion on this issue so far. Is there a
> consensus ? To summarize:
> XEN_SAVE_RESTORE depends on HIBERNATE, and in order to
> enable the save/restore functionality, the user has to enable HIBERNATE
> explicitly.
> In thread "xen: fix XEN_SAVE_RESTORE Kconfig dependencies", Jan raised
> an issue about "selecting" HIBERNATE & SWAP without the user's knowledge. That
> was resolved by making XEN_SAVE_RESTORE "depend" on HIBERNATE and
> making the user explicitly select it.
> Rafael suggested making an intermediate interface CONFIG_HIBERNATE_INTERFACE
> as an alternative but at the cost of a lot of code rework possibly.
Not really. There are a few files I'd like to depend on
CONFIG_HIBERNATE_INTERFACE initially (in kernel/power/ mostly) and the more
fine-grained differentiation can be done later over time.
So, my suggestion is to introduce CONFIG_HIBERNATE_INTERFACE as discussed
elsewhere and rework CONFIG_XEN_SAVE_RESTORE accordingly.
Thanks,
Rafael
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home