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