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

Groups > linux.kernel > #1466838 > 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:00 +0200
    Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and  __u64 from <linux/types.h>" Rob Clark <robdclark@gmail.com> - 2016-08-21 00:40 +0200
    Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and  __u64 from <linux/types.h>" Christian König <deathsimple@vodafone.de> - 2016-08-21 11:10 +0200

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

Cc'ing lkml too.

On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
> 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.

Another day dream:

Wouldn't it be nice if the uapi headers from Linux kernel would pass
a simple quality check of compiling in userspace where they are meant to be
used? Stand alone. Without magic tricks and additional libraries and their
headers. Without glibc or any other libc implementation specific additions.
The uapi headers define many parts of the Linux kernel API and ABI, and thus
compiling them also without the 'official' GNU/Linux userspace libraries
like glibc or libdrm does have some uses. For example API and ABI
compatibility checks and API/ABI/system call fuzzers.

Many headers required stdint.h types but Linux kernel headers do not
define them in userspace, and then Linus has said that uapi headers
should use the linux/types.h with double underscores. Thus my patches
for fixing trivial compile errors turned into changing several stdint.h
definitions to linux/types.h.

Yes, there have been some regressions in this work but to err is human.
What is the actual problem and how can we (yes, including me) try to
solve it?

-Mikko

[toc] | [next] | [standalone]

#1466881

On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> 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.
>
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used? Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.

The problem is, for the most part, the driver specific gpu related
ioctl interfaces are not intended for general public consumption.
They have one consumer, ie. libdrm_$drivername (or perhaps mesa
directly).  They are complex interfaces, because GPUs are complex.
They are not intended to be used directly (or for the most part, even
indirectly) by random userspace applications.  And in fact the uapi
headers exported from kernel are not actually ever used.  (ie.
libdrm_$drivername uses it's own copy internally within libdrm.)

So Linus's argument against stdint types, as weak as it is, doesn't
even apply for gpu driver specific ioctls.

BR,
-R


> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

#1466951

Am 20.08.2016 um 19:58 schrieb Mikko Rapeli:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> 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.
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used?

libdrm has a whole bunch of unit tests exercising the kernel UAPI 
headers for both API and ABI compatibility.

So to be honest I see your good intentions here, but no those checks are 
completely useless for us.

Christian.

>   Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.
>
> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web