Message-ID: <CAAxE2A5Ek+YRcj9yb8G-N_W2iQXAOLe4RGvPnZnmF8re5GLj=w@mail.gmail.com>
Date:   Sat, 20 Aug 2016 20:28:16 +0200
From:   Marek Olšák <maraeo@...il.com>
To:     Mikko Rapeli <mikko.rapeli@....fi>
Cc:     Emil Velikov <emil.l.velikov@...il.com>,
        Christian König <deathsimple@...afone.de>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and
 __u64 from <linux/types.h>"

On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli <mikko.rapeli@....fi> wrote:
> Cc'ing lkml.
>
> On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov <emil.l.velikov@...il.com> wrote:
>> > On 19 August 2016 at 15:26, Christian König <deathsimple@...afone.de> wrote:
>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>> >>>
>> >>> From: Marek Olšák <marek.olsak@....com>
>> >>>
>> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>> >>>
>> >>> See the comment in the code. Basically, don't do cleanups in this header.
>> >>>
>> >>> Signed-off-by: Marek Olšák <marek.olsak@....com>
>> >>
>> >>
>> >> I completely agree with you that this was a bad move, but I fear that we
>> >> will run into opposition with that.
>> >>
>> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
>> > READ COMMENT IN ALL CAPS.
>> >
>> > Story time:
>> > I was dreaming of a day were we can stop installing these headers,
>> > thus making deprecation a bit easier process.
>> > Yet after failing to convince Dave and Daniel on a number of occasions
>> > I've accepted that those headers _are_ here to stay. And yes they
>> > _are_ the UAPI, even though no applications are meant to use them but
>> > the libdrm 'version'.
>> > Thus any changes to the libdrm ones should be a mirror of the ones
>> > here and libdrm should _not_ differ.
>> >
>> > But let's ignore all that and imagine that those headers are _not_
>> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
>> > but the kernel __uX ones. The series that did these changes had a fair
>> > few references why we want that.
>> >
>> > Yes, I can imagine that the situation isn't ideal, and/or not that
>> > clear. Then again a check with git log should have straightened things
>> > out.
>> > If not _please_ help us improve this (documentation and/or others).
>> >
>> >
>> > And last but not least, please share with up what inspired this -
>> > (build/runtime) regression, attempted sync with libdrm, other ?
>>
>> Syncing with libdrm became difficult. I'd like the diff between kernel
>> and libdrm to be as small as possible.
>>
>> We must take into account that the uapi headers can potentially be
>> implemented by a different OS. That's why they are in libdrm and
>> that's why nobody should make random changes to them in the kernel
>> tree. Do not think like a kernel developer isolated in Linux and just
>> consider the broader use case. If you do, you'll realize that it
>> simply doesn't make sense to use the __uX types here.
>
> When libdrm is combined with Linux kernel, then libdrm should be using
> the uapi headers from the kernel. For various reasons there are embedded
> kernel header copies in libdrm, glibc and basically everywhere but there
> should not be need for that.

You quoted what I had written but you didn't read it.

>
> What exact problems did you now encounter with libdrm? Did something fail
> to compile on Linux or other OS'es?

Read the thread again. I described the problem clearly.

Marek

Powered by blists - more mailing lists