Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1466840 > unrolled thread

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>"

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and  __u64 from <linux/types.h>" Mikko Rapeli <mikko.rapeli@iki.fi> - 2016-08-20 20:10 +0200
    Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and  __u64 from <linux/types.h>" Marek Olšák <maraeo@gmail.com> - 2016-08-20 20:30 +0200
      Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and  __u64 from <linux/types.h>" Marek Olšák <maraeo@gmail.com> - 2016-08-20 20:40 +0200

#1466840 — Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>"

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@gmail.com> wrote:
> > On 19 August 2016 at 15:26, Christian König <deathsimple@vodafone.de> wrote:
> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
> >>>
> >>> From: Marek Olšák <marek.olsak@amd.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@amd.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.

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

-Mikko

[toc] | [next] | [standalone]

#1466846

On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli <mikko.rapeli@iki.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@gmail.com> wrote:
>> > On 19 August 2016 at 15:26, Christian König <deathsimple@vodafone.de> wrote:
>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>> >>>
>> >>> From: Marek Olšák <marek.olsak@amd.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@amd.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

[toc] | [prev] | [next] | [standalone]

#1466851

On Sat, Aug 20, 2016 at 8:28 PM, Marek Olšák <maraeo@gmail.com> wrote:
> On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli <mikko.rapeli@iki.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@gmail.com> wrote:
>>> > On 19 August 2016 at 15:26, Christian König <deathsimple@vodafone.de> wrote:
>>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>> >>>
>>> >>> From: Marek Olšák <marek.olsak@amd.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@amd.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.

Here's why libdrm can't use the uapi headers: It would break the very
common use case and that is building the latest userspace driver stack
on top of an old kernel. The userspace needs the latest headers, not
the installed ones. Only then is it fully compatible both ways.

Marek

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web