Hi,
On 2016/5/10 20:50, Arnd Bergmann wrote:
On Tuesday 10 May 2016 20:39:41 Zhangjian wrote:
Hi,
On 2016/5/10 19:48, Arnd Bergmann wrote:
On Tuesday 10 May 2016 17:47:26 Zhangjian wrote:
On 2016/5/10 16:36, Arnd Bergmann wrote:
On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
On 2016/5/6 20:37, Yury Norov wrote:
"include/uapi/asm-generic/posix_types.h" is uapi, we could not check
"ARCH_32BIT_OFF_T" here. Besides, the `__kernel_long_t` is long which
mean it is 32bit in ILP32. should we define something like x32?
```
diff --git a/arch/arm64/include/uapi/asm/posix_types.h b/arch/arm64/include/uapi/asm/posix_types.h
index 7985ff6..9baa8d3 100644
--- a/arch/arm64/include/uapi/asm/posix_types.h
+++ b/arch/arm64/include/uapi/asm/posix_types.h
glibc does not use the definition of __kernel_off_t, it has its own
copy, so changing the kernel headers would do nothing.
Yes, I think so. I am puzzle that how do we ensure that all the new
32bit architecture will define off_t as 64bit after introduce
ARCH_32BIT_OFF_T and do not change any other code?
This is for historic reasons: we have two sets of system calls passing
file offsets: the original ones passing a 'long' are named e.g. lseek,
pread, pwrite, fadvise, ...
The replacement syscalls that pass a 'long long' __kernel_loff_t are only
available on 32-bit architectures and have different names, e.g. llseek,
pread64, pwrite64, fadvise64, ...
On 64-bit architectures, we only provide the first set, because
__kernel_off_t was already wide enough. On old 32-bit architectures
we have both, and on new 32-bit architectures we only have the second
set, which lets us use the same definitions on all 32-bit architectures.
@@ -5,6 +5,9 @@ typedef unsigned short __kernel_old_uid_t;
typedef unsigned short __kernel_old_gid_t;
#define __kernel_old_uid_t __kernel_old_uid_t
+typedef long long __kernel_long_t;
+typedef unsigned long long __kernel_ulong_t;
+
#include <asm-generic/posix_types.h>
#endif /* __ASM_POSIX_TYPES_H */u
```
This would break all sorts of things, because __kernel_long_t/__kernel_ulong_t
are not just used for off_t but also other things.
Yes. But if we do not change __kernel_long_t and __kernel_ulong_t, the
application of ilp32 will think size of long in kernel is 32bit. Is that
correct?
No, __kernel_long_t refers to the definition of 'long' in the kernel/user
ABI, not in the kernel (except on the x86-64 "x32" ABI, which is weird).
Thanks, that is answer my question. I ask this because I saw the posix_types.h
for x32.
A 32-bit user space application must not care about how 'long' is defined
in the kernel, it should run on either 32-bit kernels or 64-bit kernels.
We don't have any plans to do an ilp32-mode kernel, but if we ever want
one, it must use the exact same ABI as the 64-bit kernel when running
ilp32 user space.
On the other hand, glibc define it own off_t in "bits/types.h":
__STD_TYPE __OFF_T_TYPE __off_t; /* Type of file sizes and offsets. */
__STD_TYPE __OFF64_T_TYPE __off64_t; /* Type of file sizes and offsets (LFS). */
in "sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h":
#define __OFF_T_TYPE __SLONGWORD_TYPE
#define __OFF64_T_TYPE __SQUAD_TYPE
If we define off_t as 64bit in glibc:
#define __OFF_T_TYPE __SQUAD_TYPE
Should We need to align all the off_t syscall to 64bit syscall in
kernel?
Yes, this is the change that I think we need to make, along with
the same change for __INO_T_TYPE and
#define __OFF_T_MATCHES_OFF64_T 1
#define __INO_T_MATCHES_INO64_T 1
If I read the rest of the glibc headers right, that should be all we need
to ensure that both off_t and off64_t match the __kernel_loff_t based
syscalls.
Ok, I will test the ltp syscall test.
With this changes, the issue I mentioned should be fixed. But we still
use mmap2 syscall for ILP32 application when we pass the offset instead
of page offset. Is it correct?
I don't remember. It's probably not important whether we have the shift
in there, as long as it's independent of the actual kernel page size and
user space and kernel agree on the calling conventions.
Well. I am ok with where to shift the pages size because we get the same
result. I was just thinking if we should get rid of the name of mmap2 in our
ILP32 porting. Actually, it is mmap but we name it as mmap2. User may confused
if they do not know the implementations.
Regards
Bamvor
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
