Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 1 April 2015 at 15:42,  <randyf at sibernet.com> wrote:
>
> Sorry, went to drafts and not to send...
>
>>>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>>>> cruft for which, I would like to think, there are no more users.
>>>>
>>>> Obviously the latter can be confirmed by Randy and friends.
>>>
>>>
>>>   I'm somewhat confused by this statement, as I still see the use of
>>> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
>>> missing something (like I said, I still have a ways to go to get to any
>>> decent level of contribution)?
>>>
>> Can you relate Solaris ports of drm to the linux one in a sentence ? Or
>> if there is a public repo somewhere that would be great.
>
>
>   We may not be as behind as you might have believed, but we are not as
> close as I would like either.
>
>   In that sentance: we have an i915 KMS driver with a decent amount of
> feature set (reasonable Haswell and DRI/DRM that would support that chipset)
> to the end of 2013 (when we had a significant amount of help from Intel),
> but we have a way too much Solaris-centric port than I would have preferred.
>
>   The public repo (Mercurial based) is at:
>
>     https://hg.java.net/hg/solaris-x11~x-s12-clone/
>
> The kernel driver source specifically at:
>
>     https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernel
>
> Note that the move of KMS drivers to this repo is recent, so there is little
> history of their evolution.
>
Right, so things are a few newer than I thought, but still a bit off
from upstream drm. Not too shocking though considering the amount of
work that goes in there ;-) The thing that struck me is that every drm
driver comes with its own version of core drm. Not critisizing, just a
bit unusual.

>>
>> Guessing that "legacy" is the keyword here - it refers to old drm
>> drivers that do user mode-setting - UMS, amongst other nasty stuff.
>> Based on the latest kernel sources the ioctls (and the struct) are
>> considered as legacy, that plus the lack of any users (very quick grep)
>> seems rather conclusive.
>
>
>   AFAICT, we aren't that bad.  And where we divert is probably more driven
> by our lack of knowlege at the time than the ability to properly converge,
> but I have lots of ground to cover before I can properly resolve the
> differences.
>
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
not all places are updated/ported to KMS ? Not a big deal though.

>>
>> If you guys are still using legacy drm drivers (for whatever reason)
>> that would be rather unfortunate. Otherwise you should be able to kill
>> off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
>>
>
>   For the most part, I have no problem with killing off any legacy layers
> that should go, as we will catch up (we do have the ability to at least
> offer a working frozen solution in the intrim).  At least in the near term,
> there are bodies actively working on getting the above driver source in sync
> with what the community has.
>
Great - glad to hear. Meanwhile I've noticed a few workarounds for
libdrm in the hg repo:
 - Force use of GCC and GNU make.
 - Disabled tests.

If you can provide some more information that would be appreciated.
Wouldn't mind squashing some bugs :-)

>>
>> Cheers,
>> Emil
>>
>
>   Ditto!
>
>   Randy
>     (enjoying a bit of downtime a couple thousand miles from home)
>
Sweet, enjoy the break.

Thanks
Emil