From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willy Tarreau Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() Date: Fri, 20 Sep 2019 19:26:09 +0200 Message-ID: <20190920172609.GA1832@1wt.eu> References: <20190912082530.GA27365@mit.edu> <20190914122500.GA1425@darwi-home-pc> <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com> <20190915052242.GG19710@mit.edu> <20190918211503.GA1808@darwi-home-pc> <20190918211713.GA2225@darwi-home-pc> <20190920134609.GA2113@pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190920134609.GA2113@pc> Sender: linux-kernel-owner@vger.kernel.org To: "Ahmed S. Darwish" Cc: Linus Torvalds , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Matthew Garrett , lkml , linux-ext4@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org List-Id: linux-api@vger.kernel.org Hi Ahmed, On Fri, Sep 20, 2019 at 03:46:09PM +0200, Ahmed S. Darwish wrote: > Problem is, glibc is still *really* slow in adopting linux syscall > wrappers, so I'm not optimistic about that... > > I still see the new system call as the sanest path, even provided > the cost of a new syscall number.. New syscalls are always a pain to deal with in userland, because when they are introduced, everyone wants them long before they're available in glibc. So userland has to define NR_xxx for each supported arch and to perform the call itself. With flags adoption is instantaneous. Just #ifndef/#define, check if the flag is supported and that's done. The only valid reason for a new syscall is when the API changes (e.g. one extra arg, a la accept4()), which doesn't seem to be the case here. Otherwise please by all means avoid this in general. Thanks, Willy