From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753335AbeAEWuS (ORCPT + 1 other); Fri, 5 Jan 2018 17:50:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56044 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752850AbeAEWuQ (ORCPT ); Fri, 5 Jan 2018 17:50:16 -0500 From: Jeff Moyer To: Benjamin LaHaise Cc: Christoph Hellwig , linux-aio@kvack.org, Avi Kivity , linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h References: <20180104080325.14716-1-hch@lst.de> <20180104080325.14716-3-hch@lst.de> <20180105164031.GK27850@kvack.org> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Fri, 05 Jan 2018 17:49:59 -0500 In-Reply-To: <20180105164031.GK27850@kvack.org> (Benjamin LaHaise's message of "Fri, 5 Jan 2018 11:40:31 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 05 Jan 2018 22:50:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi, Ben, Thanks for the quick reply. Benjamin LaHaise writes: > On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote: >> Christoph Hellwig writes: >> >> > This way it can be used for the fallback 6-argument version on >> > all architectures. >> > >> > Signed-off-by: Christoph Hellwig >> >> This is a strange way to do things. However, I was never really sold on >> libaio having to implement its own system call wrappers. That decision >> definitely resulted in some maintenance overhead. >> >> Ben, what was your reasoning for not just using syscall? > > The main issue was that glibc's pthreads implementation really sucked back > during initial development and there was a use-case for having the io_XXX > functions usable directly from clone()ed threads that didn't have all the > glibc pthread state setup for per-cpu areas to handle per-thread errno. > That made sense back then, but is rather silly today. Thanks for the background info. > Technically, I'm not sure the generic syscall wrapper is safe to use. The > io_XXX arch wrappers don't modify errno, while it appears the generic one > does. That said, nobody has ever noticed... Good point. Common architectures don't use the generic syscall wrapper, so I'm not sure we can conclude that it won't break anything. At the same time, I'm not sure I want to write and test the io_syscall6 assembly for all of the supported arches. I could save and restore errno. That sounds ugly, but less painful than the other options. Does anyone have any strong preferences? -Jeff