[haiku-development] Re: Implement 32 bit userland support for 64 bit Haiku
- From: Jérôme Duval <jerome.duval@xxxxxxxxx>
- To: haiku-development <haiku-development@xxxxxxxxxxxxx>
- Date: Fri, 18 May 2018 19:46:51 +0200
Hi,
2018-05-02 18:43 GMT+02:00 Jérôme Duval <jerome.duval@xxxxxxxxx>:
* handling 32-bit syscalls: in each syscall, we check whether the
thread runs in compatibility mode, then create the 64-bit structures
from the 32-bit ones.
Don't we need separate syscalls for 32 bit to correctly set up the
parameters? Then those should do any necessary conversions. The current
syscalls should not be changed if possible.
One exception could be the "get_{thread|...}_info()" functions, though, as
they already get the length of the structure to fill.
So I've gone forward and post the changes involved for syscalls.
https://review.haiku-os.org/#/c/haiku/+/207 kernel/x86_64:
compatibility syscalls for vfs.cpp.
https://review.haiku-os.org/#/c/haiku/+/208 kernel/x86_64:
compatibility syscalls for image.cpp.
https://review.haiku-os.org/#/c/haiku/+/209 kernel/x86_64:
compatibility syscalls for signal.cpp.
These are proposals to be able to discuss how to handle these changes:
In many syscalls the changes involve converting the types. In
signal.cpp, _user_restore_signal_frame could be more factorized.
Obviously the conversions could be moved to inline functions in the
respective headers, that would lessen indeed the noise.
Another point: In
https://review.haiku-os.org/#/c/haiku/+/191/ in the
case we need to distinguish a thread in compatibility mode,
Adrien proposed to use for more readability something like the
following, instead of a ifdef macro and flag check.
if (_COMPAT_MODE && (thread->flags & THREAD_FLAGS_COMPAT_MODE) != 0)
Opinions?
Bye
Jérôme
Other related posts:
