[Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Peter Maydell]

QEMU has something that claims to be linux-user support for
the unicore32 guest CPU. However the syscall numbers in
linux-user/unicore32 are nothing like those actually implemented
in the upstream kernel (which uses asm-generic syscall numbers).

We should either fix our unicore32 support to use the real
syscall numbers, or just drop it; since nobody has touched
linux-user/unicore32 since 2012, and there have been no
commits to target-unicore32 that aren't generic "clean up
all targets" type patches since 2012 or 2013, and nobody
has ever complained that the syscall numbers are all broken,
my initial inclination is to say we should just drop this.

Opinions?

thanks
-- PMM

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Richard Henderson]

On 05/12/2016 04:34 AM, Peter Maydell wrote:
> QEMU has something that claims to be linux-user support for
> the unicore32 guest CPU. However the syscall numbers in
> linux-user/unicore32 are nothing like those actually implemented
> in the upstream kernel (which uses asm-generic syscall numbers).
>
> We should either fix our unicore32 support to use the real
> syscall numbers, or just drop it; since nobody has touched
> linux-user/unicore32 since 2012, and there have been no
> commits to target-unicore32 that aren't generic "clean up
> all targets" type patches since 2012 or 2013, and nobody
> has ever complained that the syscall numbers are all broken,
> my initial inclination is to say we should just drop this.

No objections.


r~

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Riku Voipio]

On torstaina 12. toukokuuta 2016 17.34.42 EEST, Peter Maydell wrote:
> QEMU has something that claims to be linux-user support for
> the unicore32 guest CPU. However the syscall numbers in
> linux-user/unicore32 are nothing like those actually implemented
> in the upstream kernel (which uses asm-generic syscall numbers).
>
> We should either fix our unicore32 support to use the real
> syscall numbers, or just drop it; since nobody has touched
> linux-user/unicore32 since 2012, and there have been no
> commits to target-unicore32 that aren't generic "clean up
> all targets" type patches since 2012 or 2013, and nobody
> has ever complained that the syscall numbers are all broken,
> my initial inclination is to say we should just drop this.
>
> Opinions?

I agree. I don't have a test setup for unicore, so unicore
has seen nothing but compile testing...

Riku

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Peter Maydell]

On 20 May 2016 at 13:48, Riku Voipio <riku.voipio@iki.fi> wrote:
> On torstaina 12. toukokuuta 2016 17.34.42 EEST, Peter Maydell wrote:
>> We should either fix our unicore32 support to use the real
>> syscall numbers, or just drop it; since nobody has touched
>> linux-user/unicore32 since 2012, and there have been no
>> commits to target-unicore32 that aren't generic "clean up
>> all targets" type patches since 2012 or 2013, and nobody
>> has ever complained that the syscall numbers are all broken,
>> my initial inclination is to say we should just drop this.
>>
>> Opinions?

> I agree. I don't have a test setup for unicore, so unicore
> has seen nothing but compile testing...

I've put a note in the 2.7 Changelog saying we're going to
remove unicore32-linux-user in 2.8.

thanks
-- PMM

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Xuetao Guan]

> On 20 May 2016 at 13:48, Riku Voipio <riku.voipio@iki.fi> wrote:
>> On torstaina 12. toukokuuta 2016 17.34.42 EEST, Peter Maydell wrote:
>>> We should either fix our unicore32 support to use the real
>>> syscall numbers, or just drop it; since nobody has touched
>>> linux-user/unicore32 since 2012, and there have been no
>>> commits to target-unicore32 that aren't generic "clean up
>>> all targets" type patches since 2012 or 2013, and nobody
>>> has ever complained that the syscall numbers are all broken,
>>> my initial inclination is to say we should just drop this.
>>>
>>> Opinions?
>
>> I agree. I don't have a test setup for unicore, so unicore
>> has seen nothing but compile testing...
>
> I've put a note in the 2.7 Changelog saying we're going to
> remove unicore32-linux-user in 2.8.
>
> thanks
> -- PMM
>

Hi, peter.
I'm the maintainer of target-unicore32.
Though there's no commit since 2012, we're using qemu (but old version) to
test our new kernel and software-images.
I'll upgrade to new qemu and fix syscall problem.
Thanks.

Xuetao

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Peter Maydell]

On 14 June 2016 at 14:43, Xuetao Guan <gxt@mprc.pku.edu.cn> wrote:
>> On 20 May 2016 at 13:48, Riku Voipio <riku.voipio@iki.fi> wrote:
>>> On torstaina 12. toukokuuta 2016 17.34.42 EEST, Peter Maydell wrote:
>>>> We should either fix our unicore32 support to use the real
>>>> syscall numbers, or just drop it; since nobody has touched
>>>> linux-user/unicore32 since 2012, and there have been no
>>>> commits to target-unicore32 that aren't generic "clean up
>>>> all targets" type patches since 2012 or 2013, and nobody
>>>> has ever complained that the syscall numbers are all broken,
>>>> my initial inclination is to say we should just drop this.
>>>>
>>>> Opinions?
>>
>>> I agree. I don't have a test setup for unicore, so unicore
>>> has seen nothing but compile testing...
>>
>> I've put a note in the 2.7 Changelog saying we're going to
>> remove unicore32-linux-user in 2.8.

> I'm the maintainer of target-unicore32.
> Though there's no commit since 2012, we're using qemu (but
> old version) to test our new kernel and software-images.
> I'll upgrade to new qemu and fix syscall problem.

Hi -- just a reminder that I would like to see the unicore32
support updated to use the correct syscall numbers if we
are not to remove the code for 2.8. You have until about
the middle of October before 2.8 softfreeze.

thanks
-- PMM

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Xuetao Guan]

> On 14 June 2016 at 14:43, Xuetao Guan <gxt@mprc.pku.edu.cn> wrote:
>>> On 20 May 2016 at 13:48, Riku Voipio <riku.voipio@iki.fi> wrote:
>>>> On torstaina 12. toukokuuta 2016 17.34.42 EEST, Peter Maydell wrote:
>>>>> We should either fix our unicore32 support to use the real
>>>>> syscall numbers, or just drop it; since nobody has touched
>>>>> linux-user/unicore32 since 2012, and there have been no
>>>>> commits to target-unicore32 that aren't generic "clean up
>>>>> all targets" type patches since 2012 or 2013, and nobody
>>>>> has ever complained that the syscall numbers are all broken,
>>>>> my initial inclination is to say we should just drop this.
>>>>>
>>>>> Opinions?
>>>
>>>> I agree. I don't have a test setup for unicore, so unicore
>>>> has seen nothing but compile testing...
>>>
>>> I've put a note in the 2.7 Changelog saying we're going to
>>> remove unicore32-linux-user in 2.8.
>
>> I'm the maintainer of target-unicore32.
>> Though there's no commit since 2012, we're using qemu (but
>> old version) to test our new kernel and software-images.
>> I'll upgrade to new qemu and fix syscall problem.
>
> Hi -- just a reminder that I would like to see the unicore32
> support updated to use the correct syscall numbers if we
> are not to remove the code for 2.8. You have until about
> the middle of October before 2.8 softfreeze.
>
> thanks
> -- PMM
>
Sure, I'll fix it in this month.
Sorry for inconvenience.

Xuetao

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[MPRC]

Hi, I'm fixing the syscall problem for linux-user/unicore32 in qemu.

I write a "hello world" program to test linux-user/unicore32 in qemu 2.7 with toolchain of uc4-1.0.5(you can download it through http://mprc.pku.edu.cn/~guanxuetao/linux/uc4-1.0.5-hard.tgz). And it's just OK.
It goes well in the old version qemu that we using, also.

Can you discribe the bug more detailed? Or how do you find that the unicore32 don't use the real syscall numbers?
How should test this? By Linux Test Project? It's not necessary to do all test in LTP.

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Riku Voipio]

On Thu, Sep 22, 2016 at 11:09:55PM +0800, MPRC wrote:
> Hi, I'm fixing the syscall problem for linux-user/unicore32 in qemu.
> 
> I write a "hello world" program to test linux-user/unicore32 in qemu 2.7 with toolchain of uc4-1.0.5(you can download it through http://mprc.pku.edu.cn/~guanxuetao/linux/uc4-1.0.5-hard.tgz). And it's just OK.
> It goes well in the old version qemu that we using, also.
> 
> Can you discribe the bug more detailed? Or how do you find that the unicore32 don't use the real syscall numbers?
> How should test this? By Linux Test Project? It's not necessary to do all test in LTP.

The problem we see is that the system call numbers in qemus
unicore32/syscall_nr.h dont match what is linux mainline kernel. From the
toolchain linked, you seem to have kernel headers and syscall numbers 
based on a custom 2.6.32 fork. If one builds unicore32 binaries based on
Linux 4.4 kernel headers, they will not work qemu. OTOH the binary built
with the toolchain you linked, would not work with linux 4.4. This
disparity is what we'd like to get fixed.

Riku

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Xuetao Guan]

> On Thu, Sep 22, 2016 at 11:09:55PM +0800, MPRC wrote:
>> Hi, I'm fixing the syscall problem for linux-user/unicore32 in qemu.
>>
>> I write a "hello world" program to test linux-user/unicore32 in qemu 2.7
>> with toolchain of uc4-1.0.5(you can download it through
>> http://mprc.pku.edu.cn/~guanxuetao/linux/uc4-1.0.5-hard.tgz). And it's
>> just OK.
>> It goes well in the old version qemu that we using, also.
>>
>> Can you discribe the bug more detailed? Or how do you find that the
>> unicore32 don't use the real syscall numbers?
>> How should test this? By Linux Test Project? It's not necessary to do
>> all test in LTP.
>
> The problem we see is that the system call numbers in qemus
> unicore32/syscall_nr.h dont match what is linux mainline kernel. From the
> toolchain linked, you seem to have kernel headers and syscall numbers
> based on a custom 2.6.32 fork. If one builds unicore32 binaries based on
> Linux 4.4 kernel headers, they will not work qemu. OTOH the binary built
> with the toolchain you linked, would not work with linux 4.4. This
> disparity is what we'd like to get fixed.
>
> Riku
>
OK, I see.
I'd send kernel-patches merge request to linus, but the patches hadn't be
merged.
I'll work on it. Hopefully it'll be done before mid Oct.

Thanks Riku and Peter

Guan Xuetao

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Riku Voipio]

> > The problem we see is that the system call numbers in qemus
> > unicore32/syscall_nr.h dont match what is linux mainline kernel. From the
> > toolchain linked, you seem to have kernel headers and syscall numbers
> > based on a custom 2.6.32 fork. If one builds unicore32 binaries based on
> > Linux 4.4 kernel headers, they will not work qemu. OTOH the binary built
> > with the toolchain you linked, would not work with linux 4.4. This
> > disparity is what we'd like to get fixed.

> OK, I see.
> I'd send kernel-patches merge request to linus, but the patches hadn't be
> merged.
> I'll work on it. Hopefully it'll be done before mid Oct.

This blocks some cleanup work in linux-user code. For example everyone has
moved over from epoll_wait to epoll_pwait. However, I can't remove the now
unneeded TARGET_NR_epoll_pwait, because nobody is keeping unicore32 syscall
list upto date.

I think we should temporarily disable the unicore32-linux-user target, and
re-enable it in be 2.8 softfreeze if the system calls get updated.

Riku

Re: [Qemu-devel] proposal: drop linux-user unicore32 support from QEMU

[Xuetao Guan]

>> > The problem we see is that the system call numbers in qemus
>> > unicore32/syscall_nr.h dont match what is linux mainline kernel. From
>> the
>> > toolchain linked, you seem to have kernel headers and syscall numbers
>> > based on a custom 2.6.32 fork. If one builds unicore32 binaries based
>> on
>> > Linux 4.4 kernel headers, they will not work qemu. OTOH the binary
>> built
>> > with the toolchain you linked, would not work with linux 4.4. This
>> > disparity is what we'd like to get fixed.
>
>> OK, I see.
>> I'd send kernel-patches merge request to linus, but the patches hadn't
>> be
>> merged.
>> I'll work on it. Hopefully it'll be done before mid Oct.
>
> This blocks some cleanup work in linux-user code. For example everyone has
> moved over from epoll_wait to epoll_pwait. However, I can't remove the now
> unneeded TARGET_NR_epoll_pwait, because nobody is keeping unicore32
> syscall
> list upto date.

Yes, Unicore32 syscalls haven't been upgraded for several years, keeping
the same as all along. Therefore, many new syscalls can't be used.

>
> I think we should temporarily disable the unicore32-linux-user target, and
> re-enable it in be 2.8 softfreeze if the system calls get updated.

Good point. Maybe, unicore32-linux-user could be re-enabled after both
kernel and glibc getting updated.

>
> Riku
>
Thanks Riku.

Xuetao