Re: [PATCH v5 09/11] nds32: Add ABI list

[Vincent Chen <vincentc at andestech dot com>]

On Fri, Jun 21, 2019 at 09:12:05PM +0800, Arnd Bergmann wrote:
> On Thu, Jun 20, 2019 at 8:43 AM Vincent Chen <vincentc@andestech.com> wrote:
> 
> > +++ b/sysdeps/unix/sysv/linux/nds32/c++-types.data
> > @@ -0,0 +1,67 @@
> > +blkcnt64_t:x
> > +blkcnt_t:l
> 
> Is there a requirement for defaulting to 32-bit blkcnt_t in glibc?
> The kernel for nds32 has only ever supported 64-bit here, so it
> seems a bit pointless to use a smaller range in user space.
> 
> > +fsblkcnt64_t:y
> > +fsblkcnt_t:m
> > +fsfilcnt64_t:y
> > +fsfilcnt_t:m
> 
> Same for these
> 
> > +loff_t:x
> > +off64_t:x
> > +off_t:l
> 
> and these
> 
> > +rlim64_t:y
> > +rlim_t:m
> 
> and these
> 
For nds32, I think your suggestions are reasonable but I have a question about
rlim_t. The 2nd argument of function sys_getrlimit and sys_setrlimit is struct
rlimit which consists of 2 __kernel_ulong_t data, rlim_cur and rlim_max, in
the kernel. If I change the type of rlim_t to unsigned long long, the data type
of these two parameters does not match between kernel and linux. I know that
if the macro __RLIM_T_MATCHES_RLIM64_T is defined as 1, glibc will replace the
system calls getrlimit and setrlimit with prlimit64, and this problem does not
exist. However, user still can use indirect system call, syscall, to issue
getrlimit and setrlimit. So, does the data type of rlim_t still keep as
unsigned long in glibc? or I need to send a patch to kernel to undefine the
__ARCH_WANT_SET_GET_RLIMIT for nds32.




> > +time_t:l
> Starting with linux-5.1, you can also use 64-bit time_t.
OK


Thanks,
Vincent Chen