From: Greg KH <greg@kroah.com>
To: Simon Ser <contact@emersion.fr>
Cc: "Jason Ekstrand" <jason.ekstrand@collabora.com>,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org,
"Daniel Vetter" <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v4] dma-buf: Add a capabilities directory
Date: Thu, 2 Jun 2022 07:40:58 +0200 [thread overview]
Message-ID: <YphNaq/JZdlTW8S7@kroah.com> (raw)
In-Reply-To: <20220601161303.64797-1-contact@emersion.fr>
On Wed, Jun 01, 2022 at 04:13:14PM +0000, Simon Ser wrote:
> To discover support for new DMA-BUF IOCTLs, user-space has no
> choice but to try to perform the IOCTL on an existing DMA-BUF.
Which is correct and how all kernel features work (sorry I missed the
main goal of this patch earlier and focused only on the sysfs stuff).
> However, user-space may want to figure out whether or not the
> IOCTL is available before it has a DMA-BUF at hand, e.g. at
> initialization time in a Wayland compositor.
Why not just do the ioctl in a test way? That's how we determine kernel
features, we do not poke around in sysfs to determine what is, or is
not, present at runtime.
> Add a /sys/kernel/dmabuf/caps directory which allows the DMA-BUF
> subsystem to advertise supported features. Add a
> sync_file_import_export entry which indicates that importing and
> exporting sync_files from/to DMA-BUFs is supported.
No, sorry, this is not a sustainable thing to do for all kernel features
over time. Please just do the ioctl and go from there. sysfs is not
for advertising what is and is not enabled/present in a kernel with
regards to functionality or capabilities of the system.
If sysfs were to export this type of thing, it would have to do it for
everything, not just some random tiny thing of one kernel driver.
So no, sorry, this is not ok to be merged.
greg k-h
next prev parent reply other threads:[~2022-06-02 5:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 16:13 [PATCH v4] dma-buf: Add a capabilities directory Simon Ser
2022-06-01 16:51 ` Christian König
2022-06-01 18:05 ` Jason Ekstrand
2022-06-02 5:40 ` Greg KH [this message]
2022-06-02 6:17 ` Simon Ser
2022-06-02 6:25 ` Greg KH
2022-06-02 6:34 ` Simon Ser
2022-06-02 6:47 ` Daniel Vetter
2022-06-06 15:10 ` Robin Murphy
2022-06-06 15:22 ` Greg KH
2022-06-06 15:44 ` Robin Murphy
2022-06-07 10:36 ` Brian Starkey
2022-06-07 10:55 ` Greg KH
2022-06-07 14:52 ` Jason Ekstrand
2022-06-07 16:01 ` Greg KH
2022-06-08 15:15 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YphNaq/JZdlTW8S7@kroah.com \
--to=greg@kroah.com \
--cc=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason.ekstrand@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).