From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50022)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gxt@mprc.pku.edu.cn>) id 1bpWOL-00021M-7U
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:08:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gxt@mprc.pku.edu.cn>) id 1bpWOG-0007uq-0O
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:08:28 -0400
Received: from mprc.pku.edu.cn ([162.105.203.9]:40987)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gxt@mprc.pku.edu.cn>) id 1bpWOF-0007u7-DY
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:08:23 -0400
Message-ID: <51824.117.114.135.40.1475136295.squirrel@mprc.pku.edu.cn>
In-Reply-To: <20160928161832.GA4904@kos.to>
References: <006C2BF7-5EF8-422A-A08C-4378D0E861F3@mprc.pku.edu.cn>
	<20160923074649.GA4827@kos.to>
	<63934.117.114.135.40.1474868720.squirrel@mprc.pku.edu.cn>
	<20160928161832.GA4904@kos.to>
Date: Thu, 29 Sep 2016 16:04:55 +0800 (CST)
From: "Xuetao Guan" <gxt@mprc.pku.edu.cn>
Reply-To: gxt@mprc.pku.edu.cn
MIME-Version: 1.0
Content-Type: text/plain;charset=gb2312
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] proposal: drop linux-user unicore32 support from
 QEMU
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: Xuetao Guan <gxt@mprc.pku.edu.cn>, MPRC <zhangheng@mprc.pku.edu.cn>, peter.maydell@linaro.org, qemu-devel@nongnu.org

>> > 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