lkml.org 
[lkml]   [2019]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] arm64/sve: fix genksyms generation
On Mon, Jun 17, 2019 at 4:59 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Mon, Jun 17, 2019 at 1:26 PM Will Deacon <will.deacon@arm.com> wrote:
> >> On Mon, Jun 17, 2019 at 12:42:11PM +0200, Arnd Bergmann wrote:
> >> I suspect I need to figure out what genksyms is doing, but I'm nervous
> >> about exposing this as an array type without understanding whether or
> >> not that has consequences for its operation.
> >
> > The entire point is genksyms is to ensure that types of exported symbols
> > are compatible. To do this, it has a limited parser for C source code that
> > understands the basic types (char, int, long, _Bool, etc) and how to
> > aggregate them into structs and function arguments. This process has
> > always been fragile, and it clearly breaks when it fails to understand a
> > particular type.
>
> Shouldn't the solution for this be to fix genksyms to be less fragile
> and more understanding? The code base doesn't seem to be full of these
> sorts of ifdef workarounds.

It is one of the things I tried before I got to the version I send.
Unfortunately
the genksyms codebase is a big complex and I quickly got lost in it.

You're welcome to volunteer fixing it though. My main problem was that
I couldn't even find out which types exactly are supported, as __uint128_t
is not even in the gcc documentation. "unsigned __int128" is a documented
type, but is also not in genksyms.

Arnd

\
 
 \ /
  Last update: 2019-06-17 17:11    [W:0.217 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site