On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli <mikko.rapeli@xxxxxx> 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@xxxxxxxxx> wrote: >> > On 19 August 2016 at 15:26, Christian König <deathsimple@xxxxxxxxxxx> wrote: >> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák: >> >>> >> >>> From: Marek Olšák <marek.olsak@xxxxxxx> >> >>> >> >>> 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@xxxxxxx> >> >> >> >> >> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
