Am 08.05.2015 um 10:37 schrieb Daniel Vetter:
dma-buf user handles are fds, which means anything allocated can be passed
around nicely already. The question really is whether we'll have one ioctl
on top of a special dev node or a syscall. I thought that in these cases
where the dev node is only ever used to allocate the real thing, a syscall
is the preferred way to go.
I'd generally prefer a /dev node instead of syscall, as they can be
dynamically allocated (loaded as module, etc), which in turn offers more
finer control (eg. for containers, etc). One could easily replace the
it with its own implementation (w/o patching the kernel directly and
reboot it).
Actually, I'm a bit unhappy with the syscall inflation, in fact I'm
not even a big friend of ioctl's - I'd really prefer the Plan9 way :p
I guess the same kind of logic as with GEM (except preferably without
the DoS security holes) applies as to why its useful to have handles to
the DMA buffers.
We have handles (well file descriptors) to dma-bufs already, I'm a bit
confused what you mean?
Just curious (as I'm pretty new to this area): how to GEM objects and
dma-bufs relate to each other ? Is it possible to directly exchange
buffers between GPUs, VPUs, IPUs, FBs, etc ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen
begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist
ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn
Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren,
weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise
nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen
Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen
Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu
behalten.
Important Notice: This message may contain confidential or privileged
information. It is intended only for the person it was addressed to. If you are
not the intended recipient of this email you may not copy, forward, disclose or
otherwise use it or any part of it in any form whatsoever. If you received this
email in error please notify the sender by replying and delete this message and
any attachments without retaining a copy.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
