termux / libandroid-shmem

System V shared memory emulation on Android using ashmem.
BSD 3-Clause "New" or "Revised" License
122 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 1 year ago

Can't you use this symbol for example ?

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

twaik commented 1 year 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 1 year 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 1 year ago

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

twaik commented 1 year ago

You also asked shmat twice

It was a typo.

twaik commented 1 year 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.