On 2014/12/19 0:13, Tim Deegan wrote:
Hi Kevin,
At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
From: Tim Deegan [mailto:t...@xen.org]
Now since the code's not going to be in 4.5 anyway, it should be
possible to _develop_ it in
Hi Kevin,
At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
> At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:t...@xen.org]
> > > Now since the code's not going to be in 4.5 anyway, it should be
> > > possible to _develop_ it in this manner, possibly
At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > Now since the code's not going to be in 4.5 anyway, it should be
> > possible to _develop_ it in this manner, possibly in a private branch,
> > even if the early stages aren't getting applied im
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Wednesday, December 10, 2014 7:12 PM
>
> Hi Kevin,
>
> Thanks for taking the time to work through this.
>
> At 03:39 + on 10 Dec (1418179184), Tian, Kevin wrote:
> > 1. It's more efficient for new people to start from a small, well-defined
>
On Wed, Dec 10, 2014 at 09:59:12AM +0800, Chen, Tiejun wrote:
> On 2014/12/9 18:22, Jan Beulich wrote:
> On 09.12.14 at 11:11, wrote:
> >>At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
> >>>Why do you always pick other than the simplest possible solution?
> >>
> >>Jan, please don't
Hi Kevin,
Thanks for taking the time to work through this.
At 03:39 + on 10 Dec (1418179184), Tian, Kevin wrote:
> 1. It's more efficient for new people to start from a small, well-defined task
> in one area, and then spanning to adjacent areas gradually. Patience must
> be given by the comm
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 10, 2014 5:01 PM
>
> >>> On 10.12.14 at 04:39, wrote:
> > 1. It's more efficient for new people to start from a small, well-defined
> > task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> >
>>> On 10.12.14 at 04:39, wrote:
> 1. It's more efficient for new people to start from a small, well-defined
> task
> in one area, and then spanning to adjacent areas gradually. Patience must
> be given by the community to help them grow;
Yes. But if a large item like the RMRR one is being pick
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Tuesday, December 09, 2014 6:11 PM
>
> At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
> > Why do you always pick other than the simplest possible solution?
>
> Jan, please don't make personal comments like this in code review. It
> can
On 2014/12/9 18:22, Jan Beulich wrote:
On 09.12.14 at 11:11, wrote:
At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
Why do you always pick other than the simplest possible solution?
Jan, please don't make personal comments like this in code review. It
can only offend and demoraliz
>>> On 09.12.14 at 11:11, wrote:
> At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
>> Why do you always pick other than the simplest possible solution?
>
> Jan, please don't make personal comments like this in code review. It
> can only offend and demoralize contributors, and deter oth
At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
> Why do you always pick other than the simplest possible solution?
Jan, please don't make personal comments like this in code review. It
can only offend and demoralize contributors, and deter other people
from joining in.
I understand th
On 2014/12/9 17:21, Jan Beulich wrote:
On 09.12.14 at 10:12, wrote:
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, wrote:
On 2014/12/8 16:51, Jan Beulich wrote:
The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
is identical and can be factored out pretty easily
>>> On 09.12.14 at 10:12, wrote:
> On 2014/12/9 16:19, Jan Beulich wrote:
> On 09.12.14 at 08:47, wrote:
>>> On 2014/12/8 16:51, Jan Beulich wrote:
The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
is identical and can be factored out pretty easily afaict.
>>>
>>> Wha
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, wrote:
On 2014/12/8 16:51, Jan Beulich wrote:
The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
is identical and can be factored out pretty easily afaict.
What about this?
struct get_reserved_device_memory {
s
>>> On 09.12.14 at 08:47, wrote:
> On 2014/12/8 16:51, Jan Beulich wrote:
>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>> is identical and can be factored out pretty easily afaict.
>
> What about this?
>
> struct get_reserved_device_memory {
> struct xen_reserved_devi
On 2014/12/8 16:51, Jan Beulich wrote:
On 08.12.14 at 08:11, wrote:
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
-if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
- &rdm, 1) )
-return -EFAULT;
+
>>> On 08.12.14 at 08:11, wrote:
> On 2014/12/4 23:50, Jan Beulich wrote:
> On 01.12.14 at 10:24, wrote:
>>>
>>> -if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>> - &rdm, 1) )
>>> -return -EFAULT;
>>> +if ( d )
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,27 +22,66 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int get_reserved_device_memory(xen_pfn_t start,
-
On 2014/12/2 16:46, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
After we intend to expost that hypercall explicitly based on
XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
this into that previous patch once Jan Ack this.
better to merge together
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ struct get_reserved_device_memory {
> unsigned int used_entries;
> };
>
> -static int get_reserved_device_memory(xen_pfn_t start,
> -
> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
>
> After we intend to expost that hypercall explicitly based on
> XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
> this into that previous patch once Jan Ack this.
better to merge together, since it's the right thing t
After we intend to expost that hypercall explicitly based on
XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
this into that previous patch once Jan Ack this.
Signed-off-by: Tiejun Chen
---
xen/common/compat/memory.c | 75 ++
xen/common/me
23 matches
Mail list logo
