On Tuesday, August 9, 2016 4:26:45 PM CEST Yury Norov wrote:
As for struct timespec inside struct stat: are you sure that special
handling in the struct stat declaration is the right thing to do, rather
than arranging for this port to define struct timespec to contain the
padding members and be appropriately aligned (with the kernel made to
ignore the high parts when struct timespec is passed to the kernel from an
ILP32 process, since those high parts are considered padding in
userspace)? Putting the padding in struct timespec so the layout is
genuinely compatible between userspace and the kernel would seem a lot
less intrusive in glibc. (Because of the pre-__USE_XOPEN2K8 case in
bits/stat.h, I suppose you'd need an implementation-namespace macro or two
somewhere for defining time_t and nanoseconds fields, that macro
automatically declaring the padding field as needed, and that macro then
being used in bits/stat.h as well as in the original definition of struct
timespec.)
It was my initial idea, but Arnd told that we cannot modify time_t and
struct timespec as it is used in some ioctls and this change may harm
compatibility.
Right. The discussion for the y2038 glibc port has progressed a bit,
and we will in fact see a way to use 64-bit glibc time_t with a kernel
that has 32-bit time_t for backwards compatibility reasons, but this
is very far from being at the point where a glibc port can make that
the only option.
I suggested to declare new time64_t and struct timespec64 and use it
in union with 32-bit versions where possible but it was rejected too.
So with 32-bit time_t/timespec, this is the only option to treat time
fields as special case and introduce a bunch of paddings.
Let's take a step back here. We had a very long discussion about the
kernel ABI, and in particular the definition of 'struct stat64' for
aarch64-ilp32. To recap, there were three options (we probably had
an implementation for each one at some point):
a) use the generic definition for 'stat64' from the architecture
independent headers: This has the downside of requiring extra
syscall entry points in the kernel for the new ABI, as the layout
is different from what 32-bit ARM uses, and our normal compat
handlers provide those.
b) use the definition from 32-bit ARM, and share the compat stat64
syscalls: This has the downside of using an awkward layout that
has the STAT64_HAS_BROKEN_ST_INO set, and has two copies of
st_ino.
c) Use the layout that is compatible with 64-bit ARM (aarch64) kernels:
The downside here is that it does not use the standard types for
the time stamps, so you end up having to handle it in an architecture
specific way in user space.
We ended up with approach c), which seemed the most future-proof
ABI, but if the decision was to not use the generic ABI, why do you
try to add this to the generic implementation? The easiest way
would be to just have a aarch64 specific conversion function that
copies the data from the kernel structure into the generic user
space structure.
Alternatively you can add a sysdeps/unix/sysv/linux/aarch64/bits/stat.h
file that defines the structure the same way that the kernel does, but
you don't need to come up with a generic way of doing this, as (almost
certainly) no other architecture will have this problem, and we will have
to solve the more general 64-bit time_t problem independently.
Joseph or Andreas can probably say which of those ways for handling
this in aarch64 specific code is better (override bits/stat.h or
convert the structure), and we can also go back to approach b)
above (using the 32-bit ARM compatible structure) if that ends
up being simpler.