This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family


On Tue, Aug 09, 2016 at 04:23:27PM +0200, Arnd Bergmann wrote:
> 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.
>  

Could you share this discussion to me?

> > 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.

This is how it was implemented initially. But Joseph requested to
re-use generic glibc code as much as possible. In fact, if we use
64-bit off_t etc, the only difference is struct timespec, and there
are 3 options we should consider to handle it:
 1. Add pads to generic structure (current).
 2. Declare stat structures in arch code (initial).
 3. Introduce riscv generic ABI - what I'm asking about here.

struct stat{,fs} layout for aarch64/ilp32 is going to be the new
standard for 32-bit ports, so I think we'd end up with 1 or 3, and
that's what Joseph tells about, if I understand him right.

> 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.
> 
> 	Arnd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]