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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AA3FC4332F for ; Tue, 31 May 2022 19:18:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347241AbiEaTS5 (ORCPT ); Tue, 31 May 2022 15:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347217AbiEaTSy (ORCPT ); Tue, 31 May 2022 15:18:54 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C36E66236 for ; Tue, 31 May 2022 12:18:53 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id y24so8535806wmq.5 for ; Tue, 31 May 2022 12:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=QV/G4PVJExKY57XFucH9uGcNnMu76eJ/OVGsDYsOIxk=; b=GcC+/wChmFe5D+lixU/ePQYx0vMtmjgY9jywtGC+tExjQD07sAc/uXheAhph4pvAzO Sdv43qQhkTojoFFX+ZjxgmxVvX0+NMfOKTRPQv/Xt6Pf+BeM7pFrMuBoOUyGP7QXVVcf s+RGAFxVlgrWtwQp6NAJofgTxsyG/3PZ3t/vPzWngz2jgePhEzYZMFJ07J6MCT6QTq4K CSdYCUDuR3/QKpYgHLVjxtsuWsCI7UbUs1hc8zcQEOdN6xNkMd00NMQ+Xy9xkNlbQfv8 ewmYprJTuaWmqLiLgBW9BJeEqbwfx9wBu8injJinul0Kqwoyb/wRwoGqtv/VE93GzufG 4pWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QV/G4PVJExKY57XFucH9uGcNnMu76eJ/OVGsDYsOIxk=; b=JJzNdjh7ncg33ZROlgIvGmYghuiJP4Z8s+9NSP4xNPty1LMH7GFcMqmDrK35C+3DKv H3IS/fmnZFnkgFAcWowLlWlkYE7Q9ZDCWoEpgffPvz1+wF4BgaczGo9wvARxk3CCVfDi qv8nfK+3ehdb1FFec2EWhxiWYWiKafNd7MxGuy8s1Zip9xd5rA7czVenwvDUJEjnY9Wk pnTcdt3Nqf58w1eSbJPvPEAiIJfePKqmM1c7lELcdD4J7IY7ZLmniEa/bNKYSC6G927E PPubIkkXOkF6ZLeOfeaODiOSc4Wy0aUKRDggWcExEYJIl5+0D50JLRUjgUsXmP2s1Bx+ 7U6A== X-Gm-Message-State: AOAM530zPAHdcdbvuQCytR5mVsMeLqjzhHUMDuX3TmUJJe0syPhA79x1 Yl8TyJTGPHQSqkLP4VWJdmQCFBjExBdhqMQe X-Google-Smtp-Source: ABdhPJwcDNCyyGGF9tXLL+3yceqJNymcMQaqK1jcouWuFSM3hjbBb4FI5vkaGlcAkdKh3wggbP0MQA== X-Received: by 2002:a1c:c917:0:b0:399:26af:3d47 with SMTP id f23-20020a1cc917000000b0039926af3d47mr16751970wmb.143.1654024732108; Tue, 31 May 2022 12:18:52 -0700 (PDT) Received: from ?IPV6:2a02:6b6a:b497:0:359:2800:e38d:e04f? ([2a02:6b6a:b497:0:359:2800:e38d:e04f]) by smtp.gmail.com with ESMTPSA id f8-20020a5d64c8000000b0020d07958bb3sm12632620wri.3.2022.05.31.12.18.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 May 2022 12:18:51 -0700 (PDT) Message-ID: <7a311f7e-a404-4ebe-f90b-af9068bab2fc@bytedance.com> Date: Tue, 31 May 2022 20:18:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [External] Re: [PATCH 0/5] io_uring: add opcodes for current working directory Content-Language: en-US To: Jens Axboe , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Cc: fam.zheng@bytedance.com References: <20220531184125.2665210-1-usama.arif@bytedance.com> From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/05/2022 19:58, Jens Axboe wrote: > On 5/31/22 12:41 PM, Usama Arif wrote: >> This provides consistency between io_uring and the respective I/O syscall >> and avoids having the user of liburing specify the cwd in sqe when working >> with current working directory, for e.g. the user can directly call with >> IORING_OP_RENAME instead of IORING_OP_RENAMEAT and providing AT_FDCWD in >> sqe->fd and sqe->len, similar to syscall interface. >> >> This is done for rename, unlink, mkdir, symlink and link in this >> patch-series. >> >> The tests for these opcodes in liburing are present at >> https://github.com/uarif1/liburing/tree/cwd_opcodes. If the patches are >> acceptable, I am happy to create a PR in above for the tests. > > Can't we just provide prep helpers for them in liburing? > We could add a io_uring_prep_unlink with IORING_OP_UNLINKAT and AT_FDCWD in liburing. But i guess adding in kernel adds a more consistent interface? and allows to make calls bypassing liburing (although i guess people probably don't bypass liburing that much :)) Making the changes in both kernel and liburing provides more of a standard interface in my opinion so maybe it looks better. But happy to just create a PR in liburing only with prep helpers as you suggested if you think that is better? Thanks!