termux / libandroid-shmem

System V shared memory emulation on Android using ashmem.
BSD 3-Clause "New" or "Revised" License
118 stars 39 forks source link

Feature request. #13

Open twaik opened 1 year ago

twaik commented 1 year ago

Sometimes termux programs are launched inside proot environment, and sometimes happens they run on devices with sysvipc support enabled in kernel. It would be nice to make libandroid-shmem detect if device/environment has shmat/shmget/shmdt syscalls support and use them. It will be usefull, i.e. when user runs Xwayland/Xvfb/other X server inside proot and MIT-SHM extension works as expected. Reverse case is also possible, i.e. when user runs proot's Xvfb server and runs termux's x11vnc there. Thank you.

Et7f3 commented 10 months ago

Can't you use this symbol for example ?

https://github.com/termux/libandroid-shmem/blob/447caef31c2d02a711770944d16f0fe8981e4600/shmem.c#L431

twaik commented 10 months ago

Of course I can. But it does not fallback to regular linux shmat syscalls. That is the reason I opened this issue...

Et7f3 commented 10 months ago

I am not a android user so won't be able to test it. However I would do something similar to https://stackoverflow.com/q/4861621/7227940 for the three syscall and if return value is -ENOSYS it would mean the syscall is not available in your linux version so I would fallback to existant code. If available I would return the value of the syscall.

Also since syscall is expensive I would remember it so in the negative case I could avoid a failing syscall. In the positive case since it would be first code path and return no special treatment is needed.

Et7f3 commented 10 months ago

You also asked shmat twice. Did you mean shmdt or shmctl ?

twaik commented 10 months ago

You also asked shmat twice

It was a typo.

twaik commented 10 months ago

I am not a android user so won't be able to test it. However I would do something similar to https://stackoverflow.com/q/4861621/7227940 for the three syscall and if return value is -ENOSYS it would mean the syscall is not available in your linux version so I would fallback to existant code. If available I would return the value of the syscall.

I've already implemented it in termux-x11.