diff mbox

[1/2] linux-user: Update m68k syscall definitions to match Linux 4.4.

Message ID 1450983599-6060-1-git-send-email-glaubitz@physik.fu-berlin.de
State New
Headers show

Commit Message

John Paul Adrian Glaubitz Dec. 24, 2015, 6:59 p.m. UTC
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
---
 linux-user/m68k/syscall_nr.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

Comments

John Paul Adrian Glaubitz Dec. 24, 2015, 7:04 p.m. UTC | #1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Laurent!

Here are, as discussed previously, my proposed patches which change the
following:

PATCH 1/2 updates the syscall table for m68k to match Linux 4.4. This
one should be very obvious.

PATCH 2/2 adds the definitions for the socket calls SOCKOP_sendmmsg and
SOCKOP_recvmmsg and wires them up with the rest of the code. The
necessary function do_sendrecvmmsg() is already present in
linux-user/syscall.c. After adding these two definitions and wiring them
up, I no longer receive an error message about the unimplemented socket
calls when running "apt-get update" on Debian unstable running on qemu
with glibc_2.21 on m68k.

Cheers,
Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWfEHBAAoJEHQmOzf1tfkTE8MQAL8csEYAtrrMy1VQlQOBj4rV
+yLUkCRYobisEplXl9mQrgJ3ATswJYvj5C2wfU6wAlzUkHoLLZ/IbJwHDY9DhplN
GlkzHqjpp7mhf8lngsrdyQqmD+06ebEGvnXA8/4xwY7zVsYpddRt31ThYBvUTrbt
OwmttTypOry9aivitjBEUehpPPa82h4bc2/Jc90THyxbbb0t90MHSTsh42wY9JPT
5ePBcMSjjXi3lab7DWyPBgT0vDEDez0WhP3xbGKP4/nRKQcdJhwxxa1yBydIgEKT
WbzOUBydO6OjeX4ZYza+gLcKqRrhqokXuUW77CLrXlv+gwon3oI4m66zUq1J1xZz
kNIe5bdIPQbJ9ShCWuvbL7y0EFH/s6IOf8dcLtX/rnJ6/QvXuZJk3j3lrIn1BHK8
7aK/I1QkPvFAl3SCpi4XkEemuvKNkgDiK73WzgKHbfBSpx8UqoXH6ws4x6hhYJEv
QvN92VPj8KTUxmtG+Lhbi/yS7kowXk4N8RO3zWU4Ul94KY8PFYVIPqkyC/DcN94F
I7a7uqKrWxurzksPLsSMhmIyY5F/vik3Kw3I7Wo9+1/qB0KhCMtFTJwefLZnWoj/
2UrjE6wItlJIvMOGHt+Ih4UrXRp52PwcAcHyM7F+fhwvN5mQvtzNJehYuM/JQJZP
qXHC3MwjACFQJme1O2KT
=oAZC
-----END PGP SIGNATURE-----
John Paul Adrian Glaubitz Dec. 25, 2015, 12:02 a.m. UTC | #2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/24/2015 10:21 PM, Laurent Vivier wrote:
> I think you should have added this description in the commit
> message of the patch.

Hmm, ok. Let's wait for other comments. I'm open to make any
improvements in this regards but I also think the changes are
easy to understand without much commenting.

> You can also create your patch series with "git format-patch -n 
> --cover-letter" to have a "[PATCH 0/2]" mail template to describe
> your series.

You are right. I was thinking about that right after I sent the
patches in :).

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWfId6AAoJEHQmOzf1tfkTitEP+gIOJgkDCKQ2+VvIjc+XRKlT
4HinsXuC4URRHWfqGw4g2Bf0GDrz5R3wtM9w+UmTNhGAyyo1dx8lJRNbcftYym65
RA2CnvbBw5KydfHI0QElla3wUn83zbU42ldWYjZcIdmTSqQ8kgJIugSXGRxBX5H3
91sCUylCdOQKBeNj69p7bPgB0+fKYFaRVfhKfd7UEHQnxGoYLr/NJrc5tkm2VCio
6WU391JTwyEvywSswk+Bn8isoEKJVIZn3zmfY7b0ba69xcgsmnuxT/Ei9tmK74wO
uZBFkb7edpm24WML4Gr6UXOraJGYh06exq1C4+NoGN3eydBL4ZAnPMkqUbsh2ITt
ZDTsJKWwbYMqehsg73+xquwG3/zkJOR5BxKbPJylAolvcbmW44/sF3iVbbObMx2r
A4ZqYW1QbSaeZXr02vxp1e0CWDN0zlS2pHWR+ShNlKOEBPLf8l3TA5Eg+crxpqaU
fKhkCEeI8JQw1AZM61XE2YR/rlGGU93zDhjxmdkrmWwHqJozZfRrf9LkhhWYaiQS
dn/9QBaHpxbSq4EmQl8YE8yn+ZbKvJ3rwSOKMRp3tXiH9TnpBPuBUpPSxfYk5nxP
nJC56ihQMi1UIYVyc1BRpPoVFbn0jaKiHtN+WSZLrpgnzIRlvrqpeCRLvyXNSivE
+0xDL+UyJKTZ20NXSzGu
=NBeh
-----END PGP SIGNATURE-----
Riku Voipio Jan. 11, 2016, 1:46 p.m. UTC | #3
Hi,

On torstaina 24. joulukuuta 2015 21.04.38 EET, John Paul Adrian Glaubitz 
wrote:
> Here are, as discussed previously, my proposed patches which change the
> following:
>
> PATCH 1/2 updates the syscall table for m68k to match Linux 4.4. This
> one should be very obvious.
>
> PATCH 2/2 adds the definitions for the socket calls SOCKOP_sendmmsg and
> SOCKOP_recvmmsg and wires them up with the rest of the code. The
> necessary function do_sendrecvmmsg() is already present in
> linux-user/syscall.c. After adding these two definitions and wiring them
> up, I no longer receive an error message about the unimplemented socket
> calls when running "apt-get update" on Debian unstable running on qemu
> with glibc_2.21 on m68k.

I've applied these changing the commit messages using the text above. 
However, a static busybox from debian/unstable doesn't work for me. With or 
without these patches I just get a target segfault.

Since debian-m68k list is talking about using qemu for builds, I take I'm 
missing something obvious here. 

Riku
Laurent Vivier Jan. 11, 2016, 1:54 p.m. UTC | #4
Le 11/01/2016 14:46, Riku Voipio a écrit :
> Hi,
> 
> On torstaina 24. joulukuuta 2015 21.04.38 EET, John Paul Adrian Glaubitz
> wrote:
>> Here are, as discussed previously, my proposed patches which change the
>> following:
>>
>> PATCH 1/2 updates the syscall table for m68k to match Linux 4.4. This
>> one should be very obvious.
>>
>> PATCH 2/2 adds the definitions for the socket calls SOCKOP_sendmmsg and
>> SOCKOP_recvmmsg and wires them up with the rest of the code. The
>> necessary function do_sendrecvmmsg() is already present in
>> linux-user/syscall.c. After adding these two definitions and wiring them
>> up, I no longer receive an error message about the unimplemented socket
>> calls when running "apt-get update" on Debian unstable running on qemu
>> with glibc_2.21 on m68k.
> 
> I've applied these changing the commit messages using the text above.
> However, a static busybox from debian/unstable doesn't work for me. With
> or without these patches I just get a target segfault.
> 
> Since debian-m68k list is talking about using qemu for builds, I take
> I'm missing something obvious here.

Not obvious. Adrian is working with my m68k branch of qemu (qemu-m68k).
Pure qemu supports only coldfire, if you want to test it, you can't use
debian. There is a coldfire image at http://wiki.qemu.org/Testing, but
of course, it doesn't use the syscalls added by these patches.

I'm currently working to be able to merge my m68k branch into mainstream
qemu. A first series of patch will be available in the few coming days.

Laurent
John Paul Adrian Glaubitz Jan. 11, 2016, 1:57 p.m. UTC | #5
Hi Riku!

On 01/11/2016 02:54 PM, Laurent Vivier wrote:
> Not obvious. Adrian is working with my m68k branch of qemu (qemu-m68k).
> Pure qemu supports only coldfire, if you want to test it, you can't use
> debian. There is a coldfire image at http://wiki.qemu.org/Testing, but
> of course, it doesn't use the syscalls added by these patches.

Thanks for merging the patches.

If you want to gives Lauren't qemu-m68k fork a try, you can follow the
guide I set up in the Debian Wiki [1]. It might be advisable though to
switch to Laurent's current 2.4.0-dev branch since the master branch
mentioned in the wiki lacks the CAS2 instruction which is used by
libpthread in glibc_2.21 or later.

On the other hand, I lost networking when using Laurent's latest
branch. I will probably have to retest again, then update the
Debian Wiki page.

Adrian

> [1] https://wiki.debian.org/M68k/sbuildQEMU
Riku Voipio Jan. 11, 2016, 2:10 p.m. UTC | #6
On maanantaina 11. tammikuuta 2016 15.54.35 EET, Laurent Vivier wrote:
>
> Le 11/01/2016 14:46, Riku Voipio a écrit :
>> Hi,
>> 
>> On torstaina 24. joulukuuta 2015 21.04.38 EET, John Paul Adrian Glaubitz
>> wrote: ...
>
> Not obvious. Adrian is working with my m68k branch of qemu (qemu-m68k).
> Pure qemu supports only coldfire, if you want to test it, you can't use
> debian. There is a coldfire image at http://wiki.qemu.org/Testing, but
> of course, it doesn't use the syscalls added by these patches.

Ok, thanks for clarification, I had forgotten that m68k in mainline Qemu 
was coldfire only. I'll be happy to add debian/m68k to my tests when the 
support
gets merged.

Riku
John Paul Adrian Glaubitz Jan. 11, 2016, 2:13 p.m. UTC | #7
On 01/11/2016 03:10 PM, Riku Voipio wrote:
> Ok, thanks for clarification, I had forgotten that m68k in mainline Qemu
> was coldfire only. I'll be happy to add debian/m68k to my tests when the
> support
> gets merged.

Laurent's master-dev branch seems to have improved quite a lot,
currently testing it. The networking issue has been resolved.

You need to apply both of my patches though as otherwise apt complains
about the missing socket calls 19/20.

Adrian
diff mbox

Patch

diff --git a/linux-user/m68k/syscall_nr.h b/linux-user/m68k/syscall_nr.h
index 25f8521..a2daba0 100644
--- a/linux-user/m68k/syscall_nr.h
+++ b/linux-user/m68k/syscall_nr.h
@@ -349,3 +349,30 @@ 
 #define TARGET_NR_process_vm_writev     346
 #define TARGET_NR_kcmp                  347
 #define TARGET_NR_finit_module          348
+#define TARGET_NR_sched_setattr         349
+#define TARGET_NR_sched_getattr         350
+#define TARGET_NR_renameat2             351
+#define TARGET_NR_getrandom             352
+#define TARGET_NR_memfd_create          353
+#define TARGET_NR_bpf                   354
+#define TARGET_NR_execveat              355
+#define TARGET_NR_socket                356
+#define TARGET_NR_socketpair            357
+#define TARGET_NR_bind                  358
+#define TARGET_NR_connect               359
+#define TARGET_NR_listen                360
+#define TARGET_NR_accept4               361
+#define TARGET_NR_getsockopt            362
+#define TARGET_NR_setsockopt            363
+#define TARGET_NR_getsockname           364
+#define TARGET_NR_getpeername           365
+#define TARGET_NR_sendto                366
+#define TARGET_NR_sendmsg               367
+#define TARGET_NR_recvfrom              368
+#define TARGET_NR_recvmsg               369
+#define TARGET_NR_shutdown              370
+#define TARGET_NR_recvmmsg              371
+#define TARGET_NR_sendmmsg              372
+#define TARGET_NR_userfaultfd           373
+#define TARGET_NR_membarrier            374
+#define TARGET_NR_mlock2                375