[PATCH] drm.h: Handle DragonFly like Linux

[PATCH] drm.h: Handle DragonFly like Linux

[François Tigeot]

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.
---
 include/uapi/drm/drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index a0ebfe7..76bea05 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -36,7 +36,7 @@
 #ifndef _DRM_H_
 #define _DRM_H_
 
-#if defined(__KERNEL__) || defined(__linux__)
+#if defined(__KERNEL__) || defined(__linux__) || defined(__DragonFly__)
 
 #include <linux/types.h>
 #include <asm/ioctl.h>
-- 
2.7.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Emil Velikov]

Hi François,

On 14 May 2016 at 08:13, François Tigeot <ftigeot@wolfpond.org> 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.
Alternatively if one insists on using the __linux__ route here, imho
it's better to just set the define it in your build.

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]

Thank you
Emil

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
See section 11
[2] https://cgit.freedesktop.org/~airlied/linux
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Francois Tigeot]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

Hi Emil,

Emil Velikov wrote:
>
> On 14 May 2016 at 08:13, François Tigeot <ftigeot@wolfpond.org> 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.

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...

> 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.

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.

> 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.

-- 
Francois Tigeot

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-drm.h-Handle-DragonFly-like-Linux.patch --]
[-- Type: text/x-patch; name="0001-drm.h-Handle-DragonFly-like-Linux.patch", Size: 1036 bytes --]

>From def927d26e72dfdaa929c9b66507598d4e666709 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Tigeot?= <ftigeot@wolfpond.org>
Date: Mon, 16 May 2016 18:17:04 +0200
Subject: [PATCH] drm.h: Handle DragonFly like Linux
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
---
 include/uapi/drm/drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3683250..fe04907 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -42,7 +42,7 @@
 #include <asm/ioctl.h>
 typedef unsigned int drm_handle_t;
 
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(__DragonFly__)
 
 #include <linux/types.h>
 #include <asm/ioctl.h>
-- 
2.7.2


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Emil Velikov]

On 16 May 2016 at 17:24, Francois Tigeot <ftigeot@wolfpond.org> wrote:
> Hi Emil,
>
> Emil Velikov wrote:
>>
>>
>> On 14 May 2016 at 08:13, François Tigeot <ftigeot@wolfpond.org> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Francois Tigeot]

On Mon, May 16, 2016 at 11:02:33PM +0100, Emil Velikov wrote:
> On 16 May 2016 at 17:24, Francois Tigeot <ftigeot@wolfpond.org> wrote:
> >
> > 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.

For DragonFly, this did work a long time ago when the drm kernel drivers
were very different from the Linux ones.

> 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' ?

Hrmm. I didn't think about libdrm at all, I only looked at the various
kernel headers.

> [Please tell me that you're not having two different definitions, drm
> header, of the interface on each side - kernel vs userspace]

I'm afraid we have. Kernel headers are not available to userland and
libdrm ones are provided by the libdrm package.

FreeBSD and NetBSD even have two different drm.h kernel headers. For some
reason they think it is a good idea to keep a separate drm implementation
from ~= 10 years ago or so.

> >> 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 ?

I guess I'll have to keep patching it out locally.
Drm drivers are developed for Linux first and foremost and I'd like to
reduce differences with upstream as much as possible.

> > 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 ;-)

Right. I forgot about it since the Solaris-derived source code I have easy
access to is illumos-gate and its drm.h hasn't been updated since 2009.

> 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 ?

They are divergent by design :-/
Making the Linux headers public and removing the #else path in libdrm's
drm.h could be the right thing to do. I'll keep thinking about it...

> 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.

I'm afraid there won't be many *BSD people around. This year, the XDC and
EuroBSDCon conferences fall on the same week-end :-(
I'm not sure which one I will be attending to at this point.

Thanks Emil,

-- 
Francois Tigeot
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[randyf]

On Tue, 17 May 2016, Francois Tigeot wrote:

>
>>> 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 ;-)

   I was hoping to change that a little, but there is still a fair amount 
of work going on in enough areas to keep us busy and not very talkative 
(I try to scan this list regularly, though).

>
> Right. I forgot about it since the Solaris-derived source code I have easy
> access to is illumos-gate and its drm.h hasn't been updated since 2009.
>

   If you are interested in the primary Solaris source, you will really 
want to looking at:

     https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel

   On thing that you will notice is that this version duplicates headers 
between libdrm and the kernel driver.  The next version (a week or so) 
will have updated this to consume libdrm headers.

>> 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 ?
>
> They are divergent by design :-/
> Making the Linux headers public and removing the #else path in libdrm's
> drm.h could be the right thing to do. I'll keep thinking about it...
>

   Removing the #else path will cause Solaris compiles to fail as it does 
consume that side of the conditional (though, as we patch this file and 
don't use it as is, it would be trivial to add it or any other 
Solaris-specific requirements back in).

   From a Solaris perspective, I don't see how this file can ever -not- 
have conditional compile statements or be patched to support Solaris, as 
there are sufficient differences requiring at least minor changes.

>> 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.
>
> I'm afraid there won't be many *BSD people around. This year, the XDC and
> EuroBSDCon conferences fall on the same week-end :-(
> I'm not sure which one I will be attending to at this point.
>
> Thanks Emil,
>
> -- 
> Francois Tigeot


   Not sure yet if I will be attending either.  But would happily provide 
any input on this either in person (if I am there), or via email.

   Cheers!

 	---- Randy
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Francois Tigeot]

Hi Randy,

randyf@sibernet.com wrote:
>
>    If you are interested in the primary Solaris source, you will really
> want to looking at:
>
> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel

Thanks. This doesn't look like a git repository though.
How can I clone it ?

>> They are divergent by design :-/
>> Making the Linux headers public and removing the #else path in libdrm's
>> drm.h could be the right thing to do. I'll keep thinking about it...
>
>    Removing the #else path will cause Solaris compiles to fail as it
> does consume that side of the conditional (though, as we patch this file
> and don't use it as is, it would be trivial to add it or any other
> Solaris-specific requirements back in).

I was only thinking about patching our libdrm package here, not changing 
the upstream version.

>    From a Solaris perspective, I don't see how this file can ever -not-
> have conditional compile statements or be patched to support Solaris, as
> there are sufficient differences requiring at least minor changes.

I'd still like to only use the Linux version by default, both in kernel 
and userland.
I guess at this point the only way to do that without breaking Solaris 
is to either use local patches or change the logic of the #if directives 
to replace the Linux check with a !Solaris one.

>> I'm afraid there won't be many *BSD people around. This year, the XDC and
>> EuroBSDCon conferences fall on the same week-end :-(
>> I'm not sure which one I will be attending to at this point.
>
>    Not sure yet if I will be attending either.  But would happily
> provide any input on this either in person (if I am there), or via email.

Dri-devel seems to still be the best place for now :)

Cheers,

-- 
Francois Tigeot
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[randyf]

On Tue, 17 May 2016, Francois Tigeot wrote:

> Hi Randy,
>
> randyf@sibernet.com wrote:
>>
>>    If you are interested in the primary Solaris source, you will really
>> want to looking at:
>> 
>> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel
>
> Thanks. This doesn't look like a git repository though.
> How can I clone it ?
>

   Yea, it's a mercurial repository.  However, it is also browsable in that 
link, if you were interested in specific files (drm.h - at least for now - 
is in sys/drm).

>>> They are divergent by design :-/
>>> Making the Linux headers public and removing the #else path in libdrm's
>>> drm.h could be the right thing to do. I'll keep thinking about it...
>>
>>    Removing the #else path will cause Solaris compiles to fail as it
>> does consume that side of the conditional (though, as we patch this file
>> and don't use it as is, it would be trivial to add it or any other
>> Solaris-specific requirements back in).
>
> I was only thinking about patching our libdrm package here, not changing the 
> upstream version.

   It is likely we will continue patching, but do want to limit how much we 
actually have to do (will likely be mostly limited to type conversions). 
At some time, though, I may look into suggesting some of the changes 
upstream (since there already is blocking for __linux__, it shouldn't be 
that bad to add __sun).

>
>>    From a Solaris perspective, I don't see how this file can ever -not-
>> have conditional compile statements or be patched to support Solaris, as
>> there are sufficient differences requiring at least minor changes.
>
> I'd still like to only use the Linux version by default, both in kernel and 
> userland.
> I guess at this point the only way to do that without breaking Solaris is to 
> either use local patches or change the logic of the #if directives to replace 
> the Linux check with a !Solaris one.

   For Solaris __linux__ implies !Solaris, so there is no difference.  At 
that specific point in the file, there are header inclusions which don't 
(and probably never will) have a Solaris equivilent.  So I either have to 
patch or add a Solaris conditional anyway (even with the Solaris wrapper, 
it won't be 100% compile compatible).

>>> I'm afraid there won't be many *BSD people around. This year, the XDC and
>>> EuroBSDCon conferences fall on the same week-end :-(
>>> I'm not sure which one I will be attending to at this point.
>>
>>    Not sure yet if I will be attending either.  But would happily
>> provide any input on this either in person (if I am there), or via email.
>
> Dri-devel seems to still be the best place for now :)
>

   Indeed (though as I mentioned previously, I'm pretty sparse here, mostly 
just trying to keep up).

> Cheers,

   Same!

 	---- Randy

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm.h: Handle DragonFly like Linux

[Ed Maste]

On 17 May 2016 at 01:26, Francois Tigeot <ftigeot@wolfpond.org> wrote:
>
> FreeBSD and NetBSD even have two different drm.h kernel headers. For some
> reason they think it is a good idea to keep a separate drm implementation
> from ~= 10 years ago or so.

No, we (FreeBSD) don't think it's a good idea. It's an unfortunate
situation that we've ended up in, and is going to take some effort to
clean up, but is not a desired long-term state.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel