SHM buffer pool and file offset
ppaalanen at gmail.com
Fri Oct 14 07:52:41 UTC 2016
On Thu, 13 Oct 2016 19:27:32 +0200
Richard Röjfors <richard.rojfors at gmail.com> wrote:
> Hi all,
> I have a situation where I use shared memory buffers and think it would
> be very handy to be able to pass on the file offset to a create_pool call.
> Right now the implementation takes for granted that it should mmap
> size bytes from the beginning of the file (offset 0).
> The case I see is where buffers are coming in from peripherals at specified
> physical addresses.
> These are in the upper area of the system memory of the device,
> so mapping /dev/mem from 0 is not nice since it would result in mapping up
> the complete system memory to cover the chunks in the upper part.
> Of course I could implement a piece of code in the kernel which would map
> the corresponding memory at offset 0, but why not let wayland be a bit more
> I have modified the create_pool to pass on the offset, and I guess this could
> be of use for others too.
> If would break the ABI of create_pool if not another call, like
> create_pool_at, with the additional parameter is added.
> Is this worth upstreaming or considered not being a mainline use case?
sorry, I don't think your use case is valid. /dev/mem is not meant to
be used for any sort of "normal operations" in a system, opening it
requires root so you don't even have access to it, plus all the
dangers of accidentally poking a wrong address, plus it being an easy
way to crack a system if you ever do get access to it. Userspace
should never be using physical addresses to begin with.
wl_shm is not really meant for passing around device memory blocks, and
using wl_shm removes the opportunity for using the memory directly by a
GPU or a display device.
If you want to pass blocks of device memory around directly, please take
a look at
and about adding dmabuf capabilities to your kernel driver.
I believe that any proposition to use /dev/mem as a proper access to
device memory would be very harshly rejected by the kernel community,
so embracing dmabuf would be a better plan also for upstreaming your
device driver, not to mention avoiding the embarassment like in .
 A similar story, different file:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel