Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190617104237.2082388-1-arnd@arndb.de> <20190617112652.GB30800@fuggles.cambridge.arm.com>
 <CAK8P3a2aJNiLTyfRDqazJa2sAc-Jf-QShSZ7+4-whHSxKbLUVQ@mail.gmail.com> <87a7eg9s0o.fsf@zen.linaroharston>
In-Reply-To: <87a7eg9s0o.fsf@zen.linaroharston>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 17 Jun 2019 17:10:32 +0200
Message-ID: <CAK8P3a2evZN5aHFRtc4MQvyvgtuT+djD-gzgc5TBcMKjJ6bUYg@mail.gmail.com>
Subject: Re: [PATCH] arm64/sve: fix genksyms generation
To:     =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>
Cc:     Will Deacon <will.deacon@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Dave Martin <Dave.Martin@arm.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Peter Maydell <peter.maydell@linaro.org>,
        Alan Hayward <alan.hayward@arm.com>,
        Julien Grall <julien.grall@arm.com>,
        Marc Zyngier <marc.zyngier@arm.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Andrew Murray <andrew.murray@arm.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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