On 16 May 2016 at 17:24, Francois Tigeot <ftigeot@xxxxxxxxxxxx> wrote: > Hi Emil, > > Emil Velikov wrote: >> >> >> On 14 May 2016 at 08:13, François Tigeot <ftigeot@xxxxxxxxxxxx> wrote: >>> >>> The drm code in DragonFly uses a local Linux implementation which doesn't >>> define the __linux__ macro. >>> >>> Use __DragonFly__ instead in order to not try to compile non-Linux code. >> >> Does that meant that the workarounds in the else statements don't work >> ? I doubt that anyone will mind if we update/correct them. > > > The #else code path is not being used on DragonFly and actually breaks > kernel compilation. > I guess what I'm wondering here is where they working at some point in the past ? What was wrong with scheme in the first place ? Surely things weren't that bad. > FreeBSD is currently using an old copy of drm.h but is also planning to use > some Linux wrappers with the relevant types defined in <linux/types.h> > > OpenBSD uses a modified copy of drm.h and removed the whole #else path > except for a "typedef unsigned long drm_handle_t;" line. > > NetBSD is also using a modified copy of this file with its own #ifdef > __NetBSD__ checks and another definition of drm_handle_t... > Hmm are you sure about this ... looking at OpenBSD and DragonFly repos there seems to be no changes to drm.h. Yet again I'm looking at the libdrm which is should be identical to the kernel one with the former user space 'version'. Do you define __linux__ for user space or you fall back to the 'else' ? [Please tell me that you're not having two different definitions, drm header, of the interface on each side - kernel vs userspace] >> Alternatively if one insists on using the __linux__ route here, imho >> it's better to just set the define it in your build. > > > It's not really possible for me to patch gcc here since some software > depends on the operating system not advertising itself as Linux. > That sounds quite nasty. Wouldn't it be easier and quicker to beat the "else" back into shape, as opposed to trying to force things ? > On the other hand, the non-Linux code path really is unused. I didn't want > to be too intrusive in my patch but it's probably best to just remove it. > There is more to this world than Linux and BSD, there's Solaris as well. Even though they tend to be very quiet ;-) >> All that aside, for next revision/future work please check the >> documentation [1] and add your s-o-b line. Also, please base your work >> against Dave's drm-next branch [2] > > > Sorry about that, this new patch is signed and based on the drm-next branch. > No need to apologise but please inline patches - be that xorg, mesa, libdrm or kernel. If you'd like to comment alongside the updated version do so after the --- line or make sure the reply works with git am --scissors. TL;DR: Please don't diverge userspace vs kernel drm headers. Just beat it in shape so that it works in both cases (most likely the 'else' one). Hopefully ^^ does not sound to hard to achieve and/or demanding ? Thanks Emil P.S. Perhaps we should spend an hour or so over the next XDC trying to flush any remaining differences/patches in the graphics stack ? Not sure how many BSD/Solaris people will be around though. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
