From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F24B2480943 for ; Mon, 18 May 2026 14:23:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114242; cv=none; b=n8Wtwl5z2HGFOL+D7ps1i8opKgOcfG5LvQwkYbh6czvYbdusoW0Nfe/udXa/80V8TSWPlhrK8TOO928Zg435DSYRyQCB+ct/yWaTHBFYwSt82FfPn3F951po8OYuYL7PtGkXGMDj986hkhYQmm/Btl0Nm14t7uQEyxIb/gzv1qc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114242; c=relaxed/simple; bh=Ja0DTfaEYIoGmin0aywYwaWpB4UWlA4iW9ZxB9BMNMw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pxhM5PB8qnIc73isvIzuK4p1VLiMLbx9N73GWWWltNQhI8a02Lx8gmqG9f52OA6iIu6kJ9FUOKOxAt+emPXW+mQkt44vEI7khe0qV7LuQyCWV36g7ZY4TblKkhBRtvFpDizrtL98xvKQ9PP736ae6ekl/sjoGx6JA5UyWHW+Tbs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jFK1UxCj; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jFK1UxCj" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-bd11a3729e8so383703166b.0 for ; Mon, 18 May 2026 07:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779114237; x=1779719037; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m58bYDJ543WmyZ11IWytLuY71YuFJ2Bw6ePCWpryz/I=; b=jFK1UxCj/9hu/WpBG5drcZwxOWtR6cGYB4ErAsxcCoLRnUmHgxSqEAMVAolDJJrH9Z 1hdwdgmStI3zkbuwkOFKLgAduKUp4s7IUV0QrqjtVZyxKN2R7lpp0/keTjJeNXORBfRY iKxXU0l5N5r8xvhB9XCY4w6jrNvDuJXLhYZ9wYbjP+gKbOrmICrOApzAhigvnRrrinaL Gb3NRTZM32EVOdDbYX5+S47nP2KhGAiP8F7wO2/WZgTZ0Wdf97sbuXSYfnv1T9IEtqU5 Nv1u3gHY/kqeewKzSvB0u83tg+4FS0uxqPRyB/9oZfAlZtbMwcY0Wlc9g1oZrrMLTZS/ v+jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779114237; x=1779719037; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m58bYDJ543WmyZ11IWytLuY71YuFJ2Bw6ePCWpryz/I=; b=TKU8X7/4XDXex8gagX6ewgC/1LYp4kqrvsogAVBva5yxhyUWE8XcfBYp1P8povcNJT ZH4ZvUeuMu3mZR/L9n1NH0hV26mPXTpGwQehNr9HE5MEAo6eoJ9Ph8cPKNrWKUc21tgY F0DqAAS2BmPhPpR4e9X+pUaf2QUn9vAXvXFtqhcxC0YgOsncFJMT4UvZ/0PetcPobLX3 1K95TNt6+YJJb7M237H0B+v2edxlisbt2P4xO7yHCbedZEgkn1D5mpmY2v5mBQX8zK7k tsRLh4dsVZCn2jUAk1PRyfFVeMugdwMfOakEy4L1e/cTL+VmutscrYiF0L42ZvMl3APV o1LQ== X-Forwarded-Encrypted: i=1; AFNElJ/f+FZa07+2606vsV7NxZB3ISDnE8rsx5SbRdoamCPQBKdjiHH+0XSy5CWvUMYcaexcHsyszhRtdTouYe8=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9NcxQBvFfaLgsWekklVui+Pu8pZUoNhVniV79QVEY6P1O0o5i 2cYGXEZD4X0Zftztj9tNT0aBl9EL+Gx1qGKZA04RfLgZ7KzCM+OwpN5Q X-Gm-Gg: Acq92OHm7qT2+OgwMzktPNWuwEAlzrGLYxm2EF+ayzTrH5rMD1yOVBn1N2/9XfTto2S KkSZasQlVdZRiilzQP87XWPHTcE77QqcP/IhnYgQFq0sD2i/ObkFM0TRYNEpXXiD2K1apOr3nnF hRJPd7ppIG6KMkuBVw/gcHou7oaS7fJvwR/GZYcQCNoCaC7n2bm0VN8ZOsF2looZnYQpSvs7G27 CxOegaRPLKz09WpxKDXV/UJGubdAjMfCIaDPFYJU79K9xkTtFgdJsU+0ss00lM7GpS1Eppp2NaV rCFCnHOhPyG6SH9kfETMnOA610EGdWxsTtfzej78Blq7hTy4XZk85YKrQjzlpUJ6rNXB6bVOHxb fLsRAO8HltaOeoVmE6uLKS3I1T0oxTpxWKe3nlggeaS59H+ns6TfFtiksPh41KSYHDE7q3oML9G yVwuf1JvqWeqQ7dJj70CCZZOimCVRCL2NUwxAZJCp+t57dfZ0prLpqxEGoDQ0UYwjcxwbG3Je8C cizTVn04kiNImjWd5VEOhHSLjUxjYsqfqXO7TfMb3zdjHdrYEPD1sCPIlsdTQtgc2/yA7iiPrmb ZQ== X-Received: by 2002:a17:907:c291:b0:bd5:7a3:a58b with SMTP id a640c23a62f3a-bd517994249mr821357066b.46.1779114237152; Mon, 18 May 2026 07:23:57 -0700 (PDT) Received: from ?IPV6:2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c? ([2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-68310d58c79sm5325464a12.12.2026.05.18.07.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 07:23:56 -0700 (PDT) Message-ID: Date: Mon, 18 May 2026 15:23:53 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/10] lib: add dmabuf token infrastructure To: Christoph Hellwig Cc: Jens Axboe , Keith Busch , Sagi Grimberg , Alexander Viro , Christian Brauner , Andrew Morton , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Nitesh Shetty , Kanchan Joshi , Anuj Gupta , Tushar Gohad , William Power , Phil Cayton , Jason Gunthorpe References: <20260513082431.GA6461@lst.de> <20260518125326.GA5754@lst.de> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <20260518125326.GA5754@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/18/26 13:53, Christoph Hellwig wrote: > On Mon, May 18, 2026 at 11:14:09AM +0100, Pavel Begunkov wrote: >>> This is about dma-buf based I/O. So I'd expect it to be named dma-buf-io >>> and no io-dmabuf, and live in drivers/dma-buf and not the unrelated lib/. >>> But I'd like to hear from the dma-buf maintainers about that. >> >> Looking at what Ming is saying, it'd make more sense to keep some of the >> parts like iterator and the file op more flexible and not automatically >> imply dma-buf even if it's the main and for now the only medium. I.e. >> ublk/fuse can use a similar interface for mapping buffers to the server >> even without dma mappings. >> >> I don't know how the API should look like, maybe passing memfd, and dma-buf >> supports mmap, but I think it's better to call the op something like >> "register_buffer" instead and keep all it in lib/ for the same reasons. > > Let's get the current version landed. If we come up with some kind of > non-dma dmabuf in the future we can refactor it and move it around. > I'm a little skeptic we'll be able to share code as long as dmabuf > is allergic to physical addresses, though. To be fair, it's not that dma-buf specific. This lib/ code only does some resv locking, fence waiting and queuing fences, otherwise all the attaching is done by the driver behind callbacks. Switching it to some memfd could be pretty simple. But The main thing it'd need to share is iterator handling like forwarding in the block layer, and it should be fine as it's already passed as a completely opaque object with no knowledge about pages / dma / etc. for the middle layers. > lib/ is most certainly the wrong place for something that absolutely > is not library functionality but directly interacts with a few > subsystems. It only interacts with dma-buf, and even for dma-buf attachments are created by the driver. Block, nvme, io_uring are users, either using the helpers or implementing callbacks. Ok. Let's assume for the argument's sake it's not dma-buf specific, if not lib/, where would you put it? I was also assuming that dma-buf being under drivers/ is rather a relic of the past rather than the desired location, hmm? -- Pavel Begunkov