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 in a
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
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
On 10.12.14 at 04:39, kevin.t...@intel.com 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
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 5:01 PM
On 10.12.14 at 04:39, kevin.t...@intel.com 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
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
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
task
in
On 09.12.14 at 08:47, tiejun.c...@intel.com 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
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, tiejun.c...@intel.com 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
On 09.12.14 at 10:12, tiejun.c...@intel.com wrote:
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, tiejun.c...@intel.com 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
On 2014/12/9 17:21, Jan Beulich wrote:
On 09.12.14 at 10:12, tiejun.c...@intel.com wrote:
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, tiejun.c...@intel.com wrote:
On 2014/12/8 16:51, Jan Beulich wrote:
The whole if-copy-unlock-and-return-EFAULT-otherwise-increment
is
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
On 09.12.14 at 11:11, t...@xen.org 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
On 2014/12/9 18:22, Jan Beulich wrote:
On 09.12.14 at 11:11, t...@xen.org 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
On 08.12.14 at 08:11, tiejun.c...@intel.com wrote:
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
-if ( __copy_to_compat_offset(grdm-map.buffer, grdm-used_entries,
- rdm, 1) )
-return -EFAULT;
On 2014/12/8 16:51, Jan Beulich wrote:
On 08.12.14 at 08:11, tiejun.c...@intel.com wrote:
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
-if ( __copy_to_compat_offset(grdm-map.buffer, grdm-used_entries,
-
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
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com 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
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 to do
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 tiejun.c...@intel.com
---
xen/common/compat/memory.c | 75
20 matches
Mail list logo
