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 8837CC433F5 for ; Tue, 31 May 2022 21:35:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348028AbiEaVfw (ORCPT ); Tue, 31 May 2022 17:35:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233809AbiEaVfu (ORCPT ); Tue, 31 May 2022 17:35:50 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 619BF50E1F for ; Tue, 31 May 2022 14:35:49 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id s24so12996775wrb.10 for ; Tue, 31 May 2022 14:35:49 -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=q7cPNpK/kLXhrzfLG8hpxXs2i5SQM9UbFaXm5pBmiWk=; b=PV1FkrmCwNgQDmI8q8xLaJ2XXBLk0bNuhuDAAdA7z4qZycq5Kcw00mLFrAIu2AIerb aJ4XncmF1wRGhrUBOJwYE2sY42AwXhyxj+2MGoQf+bXIPVUkYNW77hJDONwaiqlOTO9b BtiMM4rWkZaUNlXNxA+N1HVP09ugDb+rIgPHBswnSKcLTO/PNaHzvTrV2tfuBryAVzBa TwPLTSz7WrYluB/KbKVt7WUxqS/gOs8qZeglcJFpA9cw2QEShrMQ0vFQywI7rrt0gmmZ htLEJNTq5WnH0e/YcE/ed7oZXgJxRwpxbG78X5YFRt1oKKpR+4Rj+cIHhSE8/puDCU6P kQUw== 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=q7cPNpK/kLXhrzfLG8hpxXs2i5SQM9UbFaXm5pBmiWk=; b=H+IXInLLk+EkJV2pkSsjKSRDV+pgrSTU+AzWBpWxnghNXW+7nTvD4trR8unCfEfir+ +tfReHYp/Gyd9lJmMZ0ejLa9pIfge5gMzM9PLhwlJl+To5PQv0QRZQAJf33oOenlNRHy bNQXN8JMGrOqbXUIyckCIhIg+Rubpl7gxzUpq9PAgj1pgrfqqh9wtADI+1tyRoP1yYuM QCwin8092P0hGfPC7PRONY+Yi0hkpA+08JykaclyvcCCgfBO5e5RMSSMqePudmin/uz5 AJK2r3zqwlI+XHvshedWdMD9s+UlVh5BnlAUZ+zEe0sv5pxlFzwLnYhfNuqWkTPn7oY6 CGSg== X-Gm-Message-State: AOAM532+9PAiLRawwwJUYhj36EG/Mc2xVh+3vR2Xmkhdu77cVstU/mnN XVs4q62pY0FiKzrJ/D81ed059A== X-Google-Smtp-Source: ABdhPJw4Mim9U84gjy0lO8KtDTbCtU1/Xmv0b6riP55K6OPLXzvaiil7aFdrqwfGiT3xnn8hZaBnYg== X-Received: by 2002:adf:d1ca:0:b0:210:1945:34c6 with SMTP id b10-20020adfd1ca000000b00210194534c6mr18528567wrd.334.1654032947950; Tue, 31 May 2022 14:35:47 -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 s14-20020a7bc38e000000b003942a244ee7sm3138190wmj.44.2022.05.31.14.35.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 May 2022 14:35:47 -0700 (PDT) Message-ID: Date: Tue, 31 May 2022 22:35:46 +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: [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> <7a311f7e-a404-4ebe-f90b-af9068bab2fc@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 20:22, Jens Axboe wrote: > On 5/31/22 1:18 PM, Usama Arif wrote: >> >> >> 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 :)) > > I'm not really aware of much that doesn't use the library, and even > those would most likely use the liburing man pages as that's all we > have. The kernel API is raw. If you use that, I would expect you to know > that you can just use AT_FDCWD! > >> 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? > > I don't disagree with that, but it seems silly to waste 5 opcodes on > something that is a strict subset of something that is already there. > Hence my suggestion would be to just add io_uring_prep_link() etc > helpers to make it simpler to use, without having to add 5 extra > opcodes. > Thanks, I have created a PR for it on https://github.com/axboe/liburing/pull/588. We can review it there if it makes sense!