From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751784AbbIGMyf (ORCPT ); Mon, 7 Sep 2015 08:54:35 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:52786 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbbIGMyd (ORCPT ); Mon, 7 Sep 2015 08:54:33 -0400 From: Arnd Bergmann To: "H. Peter Anvin" Cc: Geert Uytterhoeven , Andy Lutomirski , X86 ML , Network Development , Tulio Magno Quites Machado Filho , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexander Larsson , Cosimo Cecchi , Dan Nicholson , libc-alpha , Rajalakshmi Srinivasaraghavan , Linux-Arch Subject: Re: [PATCH] x86: Wire up 32-bit direct socket calls Date: Mon, 07 Sep 2015 14:53:12 +0200 Message-ID: <3193269.4TGcgnGPrm@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <55E75913.5050605@zytor.com> References: <55E75913.5050605@zytor.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:4smBpj2H4e7EcbZIzkLjH+LoYBorqC6j/u6Zf8h2i6RB9/NyIdY oMBpR1uQCKGD2Z3L2ra3L3JxlDlEd9k8iONJMNDz6aDuy9DuWli7qEp5D+fLBjPLXTsZHxN KUeftP+gN22/p3C6SNPM8NgSUNUBd50Z7CJXFg1QBtJUrwPUx6Kr4tFBbK4LeLLFteuSet4 8X9tE4RhhA7II9hVy2iFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yVOMXumvJts=:nFS6AEBeBMI1h34KC1+jWp PKrwGoX3J9AhPclvMl6gbr7rTgzIhhUlCjX4wDL6g79bwzMPZfhDMs8zkRAEmxe97EVu61FHC UJpVfUygX/TDQ2Bu4RuL5MMN0yqUkMEzD9jPpeP5rNYvO9fP6rLP/1C2EDy09wo0l1wHVWquL nv4U5AqPhLbRzHjHTqHum4AFp8x7y1PslFDnHlL8v981IqJLXUn/zV7VOhQFcT0HQHeN4R9lA XwetCt5TIxJE+eSo97kmwAifEbH/Yo5GJ1M3Svs4R8XaxZuMMr9dHdcael3ttA5sB0ggT/foI NpeyqWPRKeSxTjEC1jUToPBjTYBWZh0x6B5DRnACS32HyAun7Zc/0updmUkCurY0WPuoQezTL 81HRjy3NHXXAZ+kfMg/5nfgZN9Lsugwum2u/6JGRAjqII/pxfTwFEJcvH6VY2IWjIFamK0gS6 oXpgBcdBOXyNjshlX+UvlTq+ap0UsC3ecrcAACl+rwbPiKatpR6Ye+guZf0ANcCeZS99qymlz ZFXW90r0EMLxHUKXeNW2E8KEK16esxPG+IAHtAvFElUbFXtP3osHeKAC+zYmJ2RHHkzPb7DBj OwlypvFOjpCi/ZszdR4xipsLOTXhzCjz17FlaZMibLGqxfCbT8QbprBKrx3/h/pFh+HR4W/G0 yhs12AXNlAkc287Nip+PR3FaIU5QmPrF6MRKWtJ36mdLSFiQrT0q+eIXnU0oAp/60ETjFjloN TQ+8WeZ12QSuaTJn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote: > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > Should all other architectures follow suit? > > Or should we follow the s390 approach: > > > > It is up to the maintainer(s), largely dependent on how likely you are > going to want to support this in your libc, but in general, socketcall > is an abomination which there is no reason not to bypass. > > So follow suit unless you have a strong reason not to. +1 In my y2038 syscall series, I'm adding a new recvmmsg64 call, and we may decide to add new setsockopt/getsockopt variants as well. This is probably not the last change to socketcall, and it would be made much easier if all architectures had separate calls here. It seems that there are very few architectures that don't already have the separate calls: $ git grep -l __NR_socketcall arch/*/include/uapi | xargs git grep -L recvmsg arch/cris/include/uapi/asm/unistd.h arch/frv/include/uapi/asm/unistd.h arch/m32r/include/uapi/asm/unistd.h arch/m68k/include/uapi/asm/unistd.h arch/mn10300/include/uapi/asm/unistd.h arch/s390/include/uapi/asm/unistd.h These are of course all examples of architectures that originally followed the i386 syscall scheme closely rather than trying to leave out obsolete calls. Arnd