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 Thu, Aug 04, 2016 at 12:40:29PM +0000, Joseph Myers wrote:
> On Thu, 4 Aug 2016, Yury Norov wrote:
> 
> > diff --git a/sysdeps/unix/sysv/linux/generic/bits/stat.h b/sysdeps/unix/sysv/linux/generic/bits/stat.h
> > index 8e3f745..85e9866 100644
> > --- a/sysdeps/unix/sysv/linux/generic/bits/stat.h
> > +++ b/sysdeps/unix/sysv/linux/generic/bits/stat.h
> > @@ -41,7 +41,7 @@
> >  /* Versions of the `xmknod' interface.  */
> >  #define _MKNOD_VER_LINUX	0
> >  
> > -#if defined __USE_FILE_OFFSET64
> > +#if defined (__USE_FILE_OFFSET64) || defined (XSTAT_IS_XSTAT64)
> 
> As has been explained to you several times, XSTAT_IS_XSTAT64 is in the 
> user's namespace and must not be referenced in any installed header.

Then I have to introduce new settings in stat.h and statfs.h like
__STAT_MATCHES_STAT64 and __STATFS_MATCHES_STATFS64. The problem is
that there are too much non-generic stat{,fs} headers in glibc, and
I have to propagate new option to this ports: x86, alpha, powerpc,
sparc, s390, mips, ia64, m68k and microblaze.

With all that, I have to introduce 3 new options under generic
sysdeps/unix/sysv/linux and dozen of platforms , 
and add another portion of conditional compilation directives to
generic code which of course does not increase readability.

I see 2 ways to avoid it:
 - introduce new riscv directory and place new code there as it is
   going to be common for all new 32-bit ports, or
 - move aarch64/ilp32 code back under platform directory as it was
   initially done.

1st option is looking too far from my direct work, but I can try to do
it if it seems like better choice. So my questions are:

 - Is everything else except namespace issues is OK?
 - should we change something in generic approach like I told above?
 - I'm worrying about __type3264() usage in case of struct timespec.
   It looks little hacky, and the code will not work if struct timespec
   (doubtedly) get changed one day, so 32-bit version will not be 2 times
   smaller than 64-bit one.
 - There's an option to introduce more generic macro for padded fields, like:
   #define __padded(type, name, npads) type name; char __##name##_pad[npads]
   (plus alignement, 32/64 and BE/LE checks).
   So __field64() will look like this:
   #define __field64(type, type64, name) __padded (type, name, sizeof (type))
   Does it make sense, or __type3264 is enough?

> > +# if SUPPORT_64BIT_TIME_TYPES
> 
> Likewise SUPPORT_64BIT_TIME_TYPES.
> 
> Please stop posting any more patches to libc-alpha until you have done a 
> thorough review of all the previous libc-alpha discussions of AArch64 
> ILP32 patches over the past few years and properly understood the issues 
> involved and properly addressed them in your patches.  By now, your patch 
> postings are just wasting people's time, and this is not acceptable; 
> there's no point seeking review if you keep ignoring the issues raised.
> 
> > +#if defined (__USE_FILE_OFFSET64) || defined (XSTAT_IS_XSTAT64)
> 
> Likewise.
> 
> > +#ifdef XSTAT_IS_XSTAT64
> 
> Likewise.
> 
> > --- a/time/time.h
> > +++ b/time/time.h
> > @@ -65,6 +65,17 @@ __USING_NAMESPACE_STD(clock_t)
> >  #endif /* clock_t not defined and <time.h> or need clock_t.  */
> >  #undef	__need_clock_t
> >  
> > +#ifndef SUPPORT_64BIT_TIME_TYPES
> 
> Likewise.
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com


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