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.
Either way, all patches in this series and the
"xen: fix XEN_SAVE_RESTORE Kconfig dependencies" were acked but havent
yet made it to either Stefano's or Rafael's tree.
Would somebody please pull it into their tree?
shriram
> Ok then, when the discussion (and the code) is completely settled I'll
> ask you if it is alright for me to pull your branch and have both in
> linux-next.
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home