| Message ID | 54C21D76.8050808@sunrus.com.cn |
|---|---|
| State | New |
| Headers | show |
On 23 January 2015 at 10:07, Chen Gang S <gang.chen@sunrus.com.cn> wrote: > It is only a typo issue, need use tswapal(target_vec[i].iov_len) for the > len. > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > linux-user/syscall.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index a66c2ae..8260ed7 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -1896,7 +1896,7 @@ static void unlock_iovec(struct iovec *vec, abi_ulong target_addr, > if (target_vec) { > for (i = 0; i < count; i++) { > abi_ulong base = tswapal(target_vec[i].iov_base); > - abi_long len = tswapal(target_vec[i].iov_base); > + abi_long len = tswapal(target_vec[i].iov_len); > if (len < 0) { > break; > } > -- > 1.9.3 (Apple Git-50) Nice catch. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> thanks -- PMM
Thank you for all of your work. I plan to let qemu support tile architecture: "can let gcc run testsuite with qemu for tile". It is really hard to me, but I should try, it is my duty (I met it, and it's within my boarder, although no one pay for me). :-) At present, I am just preparing: - Reading architecture related documents (thank tile kernel member, who let me know about all tile architecture related documents). - Reading qemu architecture related code for understanding how to add tile code for qemu. - After preparing, I should provide a schedule for it (the steps, and the time point, and the risks which I may face to). Hope I can finish preparing within this month. Welcome any ideas, suggestions and completions by any members, e.g. - Share any related documents or knowledge for architecture. - Is there any original code for tile? Maybe originally, someone tried qemu for tile, but the related code was not merged into main line. - Suggestions about the schedule: the common steps, the time resources may need, and which risks have to face to. Thanks. On 1/23/15 18:08, Peter Maydell wrote: > On 23 January 2015 at 10:07, Chen Gang S <gang.chen@sunrus.com.cn> wrote: >> It is only a typo issue, need use tswapal(target_vec[i].iov_len) for the >> len. >> >> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> >> --- >> linux-user/syscall.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/linux-user/syscall.c b/linux-user/syscall.c >> index a66c2ae..8260ed7 100644 >> --- a/linux-user/syscall.c >> +++ b/linux-user/syscall.c >> @@ -1896,7 +1896,7 @@ static void unlock_iovec(struct iovec *vec, abi_ulong target_addr, >> if (target_vec) { >> for (i = 0; i < count; i++) { >> abi_ulong base = tswapal(target_vec[i].iov_base); >> - abi_long len = tswapal(target_vec[i].iov_base); >> + abi_long len = tswapal(target_vec[i].iov_len); >> if (len < 0) { >> break; >> } >> -- >> 1.9.3 (Apple Git-50) > > Nice catch. > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > > thanks > -- PMM >
On 23 January 2015 at 10:57, Chen Gang S <gang.chen@sunrus.com.cn> wrote: > > Thank you for all of your work. > > I plan to let qemu support tile architecture: "can let gcc run testsuite > with qemu for tile". It is really hard to me, but I should try, it is my > duty (I met it, and it's within my boarder, although no one pay for me). > :-) > Welcome any ideas, suggestions and completions by any members My single biggest suggestion is to make sure you split the work up so that you can post parts of it as you go along. Typically for a target-*/ new port that looks something like * initial framework, but no instruction decode (so all instructions just throw an illegal instruction exception) * support for one or a few simple classes of instruction * gradually fill in the gaps of missing instructions This way you get the benefit of code review on your early patches, so you can write the later ones in line with the comments you get on the first patches. We also get to review the code in smaller and more manageable chunks. I think the last target code to go in was target-tricore; you could look back in the git history and the archives to get an idea of how to structure the patchset and the kinds of review comment that patchseries received. thanks -- PMM
On 23 January 2015 at 14:01, Chen Gang S <gang.chen@sunrus.com.cn> wrote: > What I shall do for tile qemu should obey the related license of qemu > (all the related code should belong to qemu upstream). If necessary to > follow some copyright working flow, please let me know, I shall follow. We don't have a copyright assignment process. I recommend reading http://wiki.qemu.org/Contribute/SubmitAPatch if you haven't already. thanks -- PMM
On 1/23/15 19:21, Peter Maydell wrote: > On 23 January 2015 at 10:57, Chen Gang S <gang.chen@sunrus.com.cn> wrote: >> >> Thank you for all of your work. >> >> I plan to let qemu support tile architecture: "can let gcc run testsuite >> with qemu for tile". It is really hard to me, but I should try, it is my >> duty (I met it, and it's within my boarder, although no one pay for me). >> :-) > >> Welcome any ideas, suggestions and completions by any members > > My single biggest suggestion is to make sure you split the work > up so that you can post parts of it as you go along. Typically > for a target-*/ new port that looks something like > * initial framework, but no instruction decode (so all instructions > just throw an illegal instruction exception) > * support for one or a few simple classes of instruction > * gradually fill in the gaps of missing instructions > > This way you get the benefit of code review on your early patches, > so you can write the later ones in line with the comments you > get on the first patches. We also get to review the code in > smaller and more manageable chunks. > > I think the last target code to go in was target-tricore; you > could look back in the git history and the archives to get an > idea of how to structure the patchset and the kinds of review > comment that patchseries received. > That sounds a good idea to me. In this way, I will bother qemu upstream frequently (which also means will get much help from qemu upstream for tile, frequently). If can get much help from qemu upstream frequently (in above way), I guess, it is possible to me to finish it: "let gcc run testsuit with tile qemu". :-) What I shall do for tile qemu should obey the related license of qemu (all the related code should belong to qemu upstream). If necessary to follow some copyright working flow, please let me know, I shall follow. Thanks.
On 1/23/15 21:55, Peter Maydell wrote: > On 23 January 2015 at 14:01, Chen Gang S <gang.chen@sunrus.com.cn> wrote: >> What I shall do for tile qemu should obey the related license of qemu >> (all the related code should belong to qemu upstream). If necessary to >> follow some copyright working flow, please let me know, I shall follow. > > We don't have a copyright assignment process. I recommend > reading http://wiki.qemu.org/Contribute/SubmitAPatch if you haven't > already. > OK, thank. I assume (or declare): - The code what I write for qemu are all provided by myself (personal), not by any companies or any organizations (no one pay for it). - The documents which I have get are all free (e.g. tile architecture related pdf files), I can reference them freely for development. - If the related code what I have provided are integrated into qemu upstream, qemu upstream have the full right for it (follow with qemu upstream own copyright). I send the mail from my company email address, the reason is gmail is broken in China, my gmail can not be used, so I have to use my another email address in these days (but my gmail is still for Signed-of-by). Welcome any suggestions and completions by any members or organizations. Thanks.
23.01.2015 13:07, Chen Gang S wrote: > It is only a typo issue, need use tswapal(target_vec[i].iov_len) for the > len. My suggestion: Subject: linux-user/syscall.c: unlock_iovec: fix typo misuse of iov_base instead of iov_len without further explanation in the message body. Applied as-is to trivial, thank you! /mjt > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > linux-user/syscall.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index a66c2ae..8260ed7 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -1896,7 +1896,7 @@ static void unlock_iovec(struct iovec *vec, abi_ulong target_addr, > if (target_vec) { > for (i = 0; i < count; i++) { > abi_ulong base = tswapal(target_vec[i].iov_base); > - abi_long len = tswapal(target_vec[i].iov_base); > + abi_long len = tswapal(target_vec[i].iov_len); > if (len < 0) { > break; > } >
diff --git a/linux-user/syscall.c b/linux-user/syscall.c index a66c2ae..8260ed7 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -1896,7 +1896,7 @@ static void unlock_iovec(struct iovec *vec, abi_ulong target_addr, if (target_vec) { for (i = 0; i < count; i++) { abi_ulong base = tswapal(target_vec[i].iov_base); - abi_long len = tswapal(target_vec[i].iov_base); + abi_long len = tswapal(target_vec[i].iov_len); if (len < 0) { break; }
It is only a typo issue, need use tswapal(target_vec[i].iov_len) for the len. Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> --- linux-user/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)