Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI

[Arnd Bergmann <arnd@arndb.de>]

On Thu, Sep 13, 2018 at 10:59 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 13 Sep 2018, Arnd Bergmann wrote:
>
> > I think the expectations are generally mismatched with reality for our
> > headers. It's something that's been bugging me for a while and that
> > is not trivial to fix. We've had developers in the past that tried to
> > ensure that each exported uapi header can be included by itself,
> > but they (I forget who last worked on that) got too frustrated over
> > time to finish the job.  What you found is clearly a bug on our side
> > and we should try to fix it.
>
> I note the recent proposed changes to make uapi headers build as C++ just
> fudges this issue, by providing dummy definitions of all the required
> types.  Which can't work for my purpose, because we need the actual
> definition of elf_gregset_t that the kernel uses when generating core
> dumps, not a dummy unsigned long[1] array, for tests of sizes and offsets
> to work.

Ah, I had missed that email thread. Since David Howells is now working
on the issue overall, I'm sure we will figure something out.

I haven't seen the part about the unsigned long[1] array, but I would
assume this is something that can and should be cahnged to make
it work for you.

> > Agreed. I think the main problem is that the kernel still provides certain
> > types that are also provided by the C library, and other kernel headers
> > have interdependencies with these.
>
> The types in question (in both linux/elfcore.h and sys/procfs.h) are of
> course types provided in both places - but in this case I'm not concerned
> about being able to include both headers at once, my test includes each in
> a separate file and compares the resulting sets of sizes and offsets (and
> if the kernel header tried to delegate to the libc header to get the type
> definitions when included from userspace code, that would defeat the point
> of my test).  If various types in the kernel header were to gain
> __kernel_* prefixes, that would be fine for my purposes.

 I need to think about this a bit more, and talk to a few other people.
A first step is probably to identify all structures that are provided
by both glibc and linux and classify them. In some cases, simply
renaming will be appropriate, in others it is not. One issue is that
we try to remain compatible with whatever behavior we had before,
and renaming e.g. 'struct stat' would work for glibc but not necessarily
all other libc implementations, unless we put some extra logic in
there to get the old name /unless/ we get included from glibc.

Another issue is structures that are intentionally ambiguous,
e.g. In the uapi headers there is an ioctl command definition
include/uapi/linux/ppdev.h:#define PPGETTIME    _IOR(PP_IOCTL, 0x95,
struct timeval)
This gets included by an application passing a pointer to
a 'struct timeval' into the kernel, which now implements two
commands, based on codes
drivers/char/ppdev.c:#define PPGETTIME32   _IOR(PP_IOCTL, 0x95, s32[2])
drivers/char/ppdev.c:#define PPGETTIME64   _IOR(PP_IOCTL, 0x95, s64[2])
so it can work with any user space.

         Arnd