From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95BDDC35246 for ; Sat, 1 Feb 2020 12:53:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6C144206F0 for ; Sat, 1 Feb 2020 12:53:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=anarazel.de header.i=@anarazel.de header.b="X/XdC0+p"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="jl1cdr4F" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726518AbgBAMxx (ORCPT ); Sat, 1 Feb 2020 07:53:53 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:39239 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726297AbgBAMxx (ORCPT ); Sat, 1 Feb 2020 07:53:53 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8AB92483 for ; Sat, 1 Feb 2020 07:53:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 01 Feb 2020 07:53:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:subject:message-id:mime-version:content-type; s= fm3; bh=djPvWJmYuTTIGdVAunT9mOFvyj3L45qe+zvD9eenmPw=; b=X/XdC0+p kUcFAMK4oyggLCtNW5qPbXFTMBFIyD6OJzMRsLLPCAcK08T5RLa6i5ydemfH/6W5 VFn1TkgYJHpelTIH6wRyO3wS0gSoknNnsy4EBc1s3c6kKqo9NwnMQowY+vI6FVs5 E8vxKB6KLJ0eGklIk2yz0gyHwSqo6vagnI5A5/4VkRApFhG6E9EdRfR7rIsAT21Z aQ1dvHvvw87mBLKzbOJxE7cclC2x4b6uQMoTAnXu5jitIdLiyAV/fIStyzGQZ9Pd mn3Rc6HVsDJ+Ze3IHQTGMQqeEyZWXArilVCjKGE/eV3BBxt55jj+x07rH8NZhrac 8OBeB+uKSZEzqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=djPvWJmYuTTIGdVAunT9mOFvyj3L4 5qe+zvD9eenmPw=; b=jl1cdr4FGIOjt7DgDrJahBvZrRTGypruBu1aKuuGIiioQ o72eiAFn6a9xkCGiLxBBtFCpm30+9/gawalYj9pfppU/859pLzkElOrwe6YS0jZs /wHv7754ytILJ3zCih+4HdpLiS4NsxQSb+OJ8vgmU9tq9hkM0oBktT5dZqDeO55W BtWMH4hAruqvecWutj8ZEjiZ232/VLfcYRbvCbd+8qz4qs3s4wlpwOLVcQ9HJ9tv 6pqCW6/nR10byhTBr6uLQ2ADzsWVL8DDkkxRP6ayy6q8rNwO6JWbGchOBgHQOVSV Lv1vhQoSzc/OWe6NKiyhf0+EQNbrPaXeNnW6PSlMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgedvgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgr iigvlhdruggvqeenucfkphepudehuddrvdduiedrudefiedriedvnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgr iigvlhdruggv X-ME-Proxy: Received: from intern.anarazel.de (unknown [151.216.136.62]) by mail.messagingengine.com (Postfix) with ESMTPA id F07FA30607B0 for ; Sat, 1 Feb 2020 07:53:51 -0500 (EST) Date: Sat, 1 Feb 2020 04:53:50 -0800 From: Andres Freund To: io-uring@vger.kernel.org Subject: liburing: expose syscalls? Message-ID: <20200201125350.vkkhezidm6ka6ux5@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org Hi, As long as the syscalls aren't exposed by glibc it'd be useful - at least for me - to have liburing expose the syscalls without really going through liburing facilities... Right now I'm e.g. using a "raw" io_uring_enter(IORING_ENTER_GETEVENTS) to be able to have multiple processes safely wait for events on the same uring, without needing to hold the lock [1] protecting the ring [2]. It's probably a good idea to add a liburing function to be able to do so, but I'd guess there are going to continue to be cases like that. In a bit of time it seems likely that at least open source users of uring that are included in databases, have to work against multiple versions of liburing (as usually embedding libs is not allowed), and sometimes that is easier if one can backfill a function or two if necessary. That syscall should probably be under a name that won't conflict with eventual glibc implementation of the syscall. Obviously I can just do the syscall() etc myself, but it seems unnecessary to have a separate copy of the ifdefs for syscall numbers etc. What do you think? [1] It's more efficient to have the kernel wake up the waiting processes directly, rather than waking up one process, which then wakes up the other processes by releasing a lock. [2] The reason one can't just use io_uring_submit_and_wait or such, is because it's not safe to call __io_uring_flush_sq(ring) while somebody else might access the ring. Greetings, Andres Freund