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

Emil Velikov emil.l.velikov at gmail.com
Thu Mar 26 11:50:27 PDT 2015


Hello Randy

On 26/03/15 16:56, randyf at sibernet.com wrote:
>>
>> Was honestly hoping that patch #1 is not required as:
>> - Getting the drm.h header in sync with the kernel will be annoying.
> 
>   Indeed.
> 
>   I have a version of drm.h that works with Solaris and *should* still
> work with all other consumers, but as I still have a ways to get fully
> to speed, am hesitant to suggest a patch (are there other issues I have
> yet to discover).
> 
Afaict the current Patch #1 will work with non-sun consumers.
Considering that the header(s) are currently out of sync (rather badly
imho), and the legacy note below would be nice if we can avoid the change.

Sometimes dri-devel can be a bit slow, so I would suggest that you post
finding/patches earlier rather than later.

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

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.

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.


Cheers,
Emil



More information about the dri-devel mailing list