| Message ID | 550F7087.2040609@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 23/03/15 01:46, Alan Coopersmith wrote: > On 03/ 9/15 05:37 AM, Emil Velikov wrote: >> The former does not imply the latter and vice-versa. One such example is >> the Sun compiler. >> >> Cc: Alan Coopersmith <alan.coopersmith@oracle.com> >> Cc: Thierry Reding <treding@nvidia.com> >> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> >> --- >> >> Hi Alan, >> Can you please take a look it this series covers the symbol visibility >> issues mentioned earlier ? In theory it should work like a charm but I >> cannot really test it :-\ > > Patch 1 of 2 breaks configure on Solaris - I get: > > checking for VALGRIND... no > checking whether cc -xc99=%all supports __attribute__((visibility))... > ./configure[13393]: set does not quote correctly, so add quotes: > double-quote^J # substitution turns \\ into \, and sed turns \ into > \.^J sed -n ^I"s//\\/g;^J^I > s/^\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\)=\(.*\)/\1=2/p"^J ;; > #(^J *)^J # : not found [No such file or directory] > ./configure[13393]: {\1+set}: bad substitution > ./configure[13992]: : cannot open > ./configure[14000]: : cannot open > ./configure[14032]: : cannot open > ./configure[14051]: : cannot open > ./configure[14128]: : cannot open > ./configure[14139]: : cannot open > ./configure[14150]: : cannot open > ./configure[14435]: : cannot open > ./configure[14563]: : cannot open > ./configure[14603]: : cannot open > ./configure[14610]: : cannot open > ./configure[14639]: : cannot open > ./configure[14671]: : cannot open > ./configure[14740]: : cannot open > ./configure[14744]: : cannot open > ./configure[14778]: : cannot open > ./configure[14928]: : cannot open > ./configure[14948]: : cannot open > ./configure[14962]: : cannot open > ./configure[14966]: : cannot open > configure: error: write failure creating > It also generated new autoconf warnings generating the configure script: > > configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > configure.ac:422: the top level > configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > configure.ac:422: the top level > autoreconf: running: > /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force > configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > configure.ac:422: the top level > autoreconf: running: > /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader > --force > configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > configure.ac:422: the top level > autoreconf: running: automake --add-missing --copy --force-missing > configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > configure.ac:422: the top level > > Both seem to have been caused by a misplaced close paren/brace pair and > are fixed by: > > --- a/configure.ac > +++ b/configure.ac > @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports > __attribute__((visibility))]) > AC_LINK_IFELSE([AC_LANG_PROGRAM([ > int foo_default( void ) __attribute__((visibility("default"))); > int foo_hidden( void ) __attribute__((visibility("hidden"))); > -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), > AC_MSG_RESULT([no])]); > +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])], > AC_MSG_RESULT([no])); > > if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then > AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports > __attribute__((visibility))]) > > (Gotta love autoconf and the mysteries of proper [] placements.) > Playing around with [] is always fun. Thanks for the fix. > After that I can build on Solaris with patch #1 applied, but patch #2 > then breaks > due to Solaris Studio 12.4 compilers being more pedantic about > prototypes in headers > having the external visibility declarations too - lots of errors of the > form: > > "intel_bufmgr.c", line 60: redeclaration must have the same or more > restrictive linker scoping: drm_intel_bo_alloc_for_render > > It looks like none of the headers have the drm_public attributes the > compiler wants > to see there. > Ouch... this explains why many places in X symbols are explicitly annotated as X_HIDDEN. From a closer look it seems to be the shorter/safe option. Plus to catch internal symbols slipping away I can add wire up a few tests at make check :-) >> Additionally can you guys build libdrm (barring the patch you sent the >> other day), or you need some parts of this ancient patch >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup >> > > That looks very much like an ancient patch we still have in our tree [1] > since > I never found out if we could upstream it or replace it from our former DRM > team. Unfortunately, they're all gone now - I've cc'ed the people who > picked > up that work - I'd already asked Randy to look at it as part of the work > he's > doing to reconcile our DRM sources with upstream. > > [1] > https://hg.java.net/hg/solaris-x11~x-s12-clone/file/4e6b5865e3ec/open-src/lib/libdrm/solaris-drm-port.patch > > > I keep a subset in my local git repo to enable building from upstream > since the > raw upstream builds don't work without at least some of it. (See > attached patches for that subset.) > Thanks ! Was honestly hoping that patch #1 is not required as: - Getting the drm.h header in sync with the kernel will be annoying. - 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. Cheers, Emil
> > 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). > - 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)? Cheers! ---- Randy
Hello Randy On 26/03/15 16:56, randyf@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
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)
On 1 April 2015 at 15:42, <randyf@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
On Sun, 5 Apr 2015, Emil Velikov wrote: >> 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 ;-) It is a bit overwhelming, so I (currently) tend to scan this list irregularly, and look for some source snapshot for porting reference. > The thing that struck me is that every drm driver comes with its own > version of core drm. Not critisizing, just a bit unusual. So technically, only one driver has it's own version, and that is mostly driven by a lack of hardware to verify it continues to work as drm changes (and is slated for removal as the hardware is obsolete and unavailable). With (currently) only one other drm driver, it would appear that the drm core is unique to it (and to some extent it is), but the evolution would be to be towards a common drm. >> >> 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. > We're hopeful that this will change in the near future (we have someone working on a radeon KMS port, which is expected to use a common drm). >> >> 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 :-) Niveditha might be a better person to answer these questions as she has more history with libdrm. I've only recently become aware of the tests, but hoping to somehow make use of them. I'm happy also to squash bugs as well, and also hoping to offer patches in the next couple of months (might need some help or understanding for those first few). >> >> Randy >> (enjoying a bit of downtime a couple thousand miles from home) >> > Sweet, enjoy the break. > It was sort of part work, part relax and nice to get away, but now back to reality. ---- Randy
On 04/05/15 11:33, randyf@sibernet.com wrote: > > > On Sun, 5 Apr 2015, Emil Velikov wrote: > >>> 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 ;-) > > It is a bit overwhelming, so I (currently) tend to scan this list > irregularly, and look for some source snapshot for porting reference. > > >> The thing that struck me is that every drm driver comes with its own >> version of core drm. Not critisizing, just a bit unusual. > > So technically, only one driver has it's own version, and that is > mostly driven by a lack of hardware to verify it continues to work as > drm changes (and is slated for removal as the hardware is obsolete and > unavailable). > > With (currently) only one other drm driver, it would appear that the > drm core is unique to it (and to some extent it is), but the evolution > would be to be towards a common drm. > > >>> >>> 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. >> > > We're hopeful that this will change in the near future (we have > someone working on a radeon KMS port, which is expected to use a > common drm). > > >>> >>> 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 :-) > IIRC, we had issues with getting drm.7 without using GNU make. And the build of libdrm_radeon was failing without using gcc. I'll revert back to Studio and get you the failures since its been a while having made the switch. We had disabled tests because of parfait failures which is part of our build process. But I think we should be able to enable it now since we have an updated version of parfait that we are building with. Thanks Niveditha
--- a/configure.ac +++ b/configure.ac @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))]) AC_LINK_IFELSE([AC_LANG_PROGRAM([ int foo_default( void ) __attribute__((visibility("default"))); int foo_hidden( void ) __attribute__((visibility("hidden"))); -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]); +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])], AC_MSG_RESULT([no])); if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))])