On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers <joseph@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
> >
> > glibc has a note that alpha lacks statfs64, any plans for that?
>
> Good catch, I missed that because all other 64-bit architectures
> have a statfs() call with 64-bit fields. I see that it also has an
> osf_statfs64 structure and system call with lots of padding and some
> oddly sized fields: f_type, f_flags and f_namemax are only 16 bits
> wide, the rest is all 64-bit.
>
> Adding the regular statfs64() should be easy enough, we just need to
> decide which layout to use:
>
> a) use the currently unused 'struct statfs64' as provided by the
> alpha uapi headers, which has a 32-bit __statfs_word but
> 64-bit f_blocks, f_bfree, f_bavail, f_files, and f_ffree.
>
> b) copy asm-generic/statfs.h to the alpha asm/statfs.h and
> change statfs64 to have the regular layout that we use
> on all other 64-bit architectures, using all 64-bit fields.
>
> The other open question for alpha (as mentioned in one of the
> patches I sent) would be whether to add get{eg,eu,g,p,pp,u}id()
> with the regular calling conventions.
I would be interested in seeing those provided on Alpha. There are
a handful of projects choosing to sidestep glibc for these syscalls
and they break on Alpha. Such projects are never keen to include
special assembler code (because the extant syscalls on Alpha are not
C ABI compliant) to support a legacy arch.
Cheers
Michael.
