Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220318171405.2728855-1-cmllamas@google.com> <CAJfpegsT6BO5P122wrKbni3qFkyHuq_0Qq4ibr05_SOa7gfvcw@mail.gmail.com>
 <Yjfd1+k83U+meSbi@google.com>
In-Reply-To: <Yjfd1+k83U+meSbi@google.com>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Mon, 21 Mar 2022 09:40:56 +0100
Message-ID: <CAJfpeguoFHgG9Jm3hVqWnta3DB6toPRp_vD3EK74y90Aj3w+8Q@mail.gmail.com>
Subject: Re: [PATCH] fuse: fix integer type usage in uapi header
To:     Carlos Llamas <cmllamas@google.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Alessio Balsini <balsini@android.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        kernel-team <kernel-team@android.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 21 Mar 2022 at 03:07, Carlos Llamas <cmllamas@google.com> wrote:
>
> On Fri, Mar 18, 2022 at 08:24:55PM +0100, Miklos Szeredi wrote:
> > On Fri, 18 Mar 2022 at 18:14, Carlos Llamas <cmllamas@google.com> wrote:
> > >
> > > Kernel uapi headers are supposed to use __[us]{8,16,32,64} defined by
> > > <linux/types.h> instead of 'uint32_t' and similar. This patch changes
> > > all the definitions in this header to use the correct type. Previous
> > > discussion of this topic can be found here:
> > >
> > >   https://lkml.org/lkml/2019/6/5/18
> >
> > This is effectively a revert of these two commits:
> >
> > 4c82456eeb4d ("fuse: fix type definitions in uapi header")
> > 7e98d53086d1 ("Synchronize fuse header with one used in library")
> >
> > And so we've gone full circle and back to having to modify the header
> > to be usable in the cross platform library...
> >
> > And also made lots of churn for what reason exactly?
>
> There are currently only two uapi headers making use of C99 types and
> one is <linux/fuse.h>. This approach results in different typedefs being
> selected when compiling for userspace vs the kernel.

Why is this a problem if the size of the resulting types is the same?

Thanks,
Miklos