This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Yury Norov <ynorov at caviumnetworks dot com>
- Cc: libc-alpha at sourceware dot org, Joseph Myers <joseph at codesourcery dot com>, schwab at suse dot de, catalin dot marinas at arm dot com, davem at davemloft dot net, szabolcs dot nagy at arm dot com, maxim dot kuvyrkov at linaro dot org, pinskia at gmail dot com, bamvor dot zhangjian at huawei dot com, fweimer at redhat dot com, Prasun dot Kapoor at cavium dot com, adhemerval dot zanella at linaro dot org
- Date: Mon, 29 Aug 2016 22:34:38 +0200
- Subject: Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family
- Authentication-results: sourceware.org; auth=none
- References: <1470304959-9944-1-git-send-email-ynorov@caviumnetworks.com> <8198988.qgYzoUMF4Q@wuerfel> <20160829160141.GA24851@yury-N73SV>
On Monday 29 August 2016, Yury Norov wrote:
> >
> > We've gone back and forth on the arm64+ilp32 definition of the
> > existing stat64 , because that one cannot easily use the same
> > generic structure. I originally thought that using the 64-bit
> > layout of 'struct stat' was a good idea for arm64, but now
> > I don't see much of an advantage either way (the existing arm32
> > 'struct stat64' layout or the existing arm64 'struct stat' layout).
> >
> > Both of them are incompatible with the default layout for all
> > other new 32-bit architectures in user space, so pick one of the
> > two for the kernel interface, and convert it to the normal layout
> > in glibc using __xstat_conv():
> >
> > - if you use the arm64 'struct stat' layout (as in the current
> > kernel patches), you need a temporary buffer with the larger
> > size and then copy over the time fields one by one
> > - if you instead use the arm32 'struct stat64' layout in the kernel,
> > the size is the same, and the conversion is a one-line
> > assignment of st_ino.
> >
> > Arnd
>
> Ok. I'll do like this. I'd prefer 1st option, because 2nd implies
> allocating big buffer on kernel side.
On the kernel side, both require allocating a buffer, the second
one is just slightly bigger. The kernel uses its own internal
'struct kstat', which gets copied into one of the other structures.
Arnd