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

[randyf at sibernet.com]

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.

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

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

>
> Cheers,
> Emil
>

   Ditto!

   Randy
     (enjoying a bit of downtime a couple thousand miles from home)