Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support

[Arnd Bergmann]

On Monday 20 August 2012, Pavel Machek wrote:
> > This patch adds support for 32-bit applications. The vectors page is a
> > binary blob mapped into the application user space at 0xffff0000 (the
> > AArch64 toolchain does not support compilation of AArch32 code). Full
> > compatibility with ARMv7 user space is supported. The use of deprecated
> > ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
> > AArch64 kernels and unaligned LDM/STM is not supported.
> > 
> > Please note that only the ARM 32-bit EABI is supported, so no OABI
> > compatibility.
> 
> > +struct compat_statfs {
> > +     int             f_type;
> > +     int             f_bsize;
> > +     int             f_blocks;
> > +     int             f_bfree;
> > +     int             f_bavail;
> > +     int             f_files;
> > +     int             f_ffree;
> > +     compat_fsid_t   f_fsid;
> > +     int             f_namelen;      /* SunOS ignores this field. */
> 
> I'm sure it does. But is it good comment?

Good catch. It seems that some of the other compat platforms (x86,
sparc, powerpc) have the same thing. I guess the real solution would
be to introduce an asm-generic/compat.h file that contains a bunch
of those definitions, like

#ifndef compat_timespec
struct compat_timespec {
        compat_time_t   tv_sec;
        s32             tv_nsec;
};
#endif

#ifndef compat_timeval
struct compat_timeval {
        compat_time_t   tv_sec;
        s32             tv_usec;
};
#endif

#ifndef compat_sysctl
struct compat_sysctl {
        unsigned int    name;
        int             nlen;
        unsigned int    oldval;
        unsigned int    oldlenp;
        unsigned int    newval;
        unsigned int    newlen;
        unsigned int    __unused[4];
};
#endif

For the most part, arch/tile should have useful defaults, though not in the
case of struct statfs, because its 32 bit version does not have a statfs syscall
(it only has statfs64).

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/