Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-2082

Remove x86 Assembler Code from zookeeper

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.1.0
    • Component/s: build
    • Labels:
      None

      Description

      Compilation on OpenPower fails for zookeeper, since upstream contains x86 Assembler in mt_processor.c .

      Incorporate an fix from zookeeper 3.5 branch to remove assembler from this particular file

        Issue Links

          Activity

          Hide
          oflebbe Olaf Flebbe added a comment -

          Committed

          Show
          oflebbe Olaf Flebbe added a comment - Committed
          Hide
          cos Konstantin Boudnik added a comment -

          Yup, thanks!
          Also, can we get a JIRA to track down the future removal?

          Show
          cos Konstantin Boudnik added a comment - Yup, thanks! Also, can we get a JIRA to track down the future removal?
          Hide
          oflebbe Olaf Flebbe added a comment -

          Right. Ok, to commit ?

          Show
          oflebbe Olaf Flebbe added a comment - Right. Ok, to commit ?
          Hide
          cos Konstantin Boudnik added a comment -

          Continuing the conversation started on BIGTOP-1934, I have linked this JIRA to the appropriate ZK ticket. We clearly need to track the release of ZK 3.5 to remove this patch once it is out.

          Show
          cos Konstantin Boudnik added a comment - Continuing the conversation started on BIGTOP-1934 , I have linked this JIRA to the appropriate ZK ticket. We clearly need to track the release of ZK 3.5 to remove this patch once it is out.
          Hide
          cos Konstantin Boudnik added a comment -

          Well, it is a platform specific one (poor wording on my side, I guess My point still stands: we are making decisions on what to do fix in the upstream and what not. It is fine if we decide to do in the sound mind and not simply as a one-time thing. From the historical standpoint though: we never been doing this and were steering clear of the distribution games so we can remain the only data stack 100% based on Apache genuine released. This stance could be right or wrong, but it is what it is. If we are seeing a need to change it - perhaps it is a time. But I would try to work with ZK community to incorporate the fix into their next release.

          Show
          cos Konstantin Boudnik added a comment - Well, it is a platform specific one (poor wording on my side, I guess My point still stands: we are making decisions on what to do fix in the upstream and what not. It is fine if we decide to do in the sound mind and not simply as a one-time thing. From the historical standpoint though: we never been doing this and were steering clear of the distribution games so we can remain the only data stack 100% based on Apache genuine released. This stance could be right or wrong, but it is what it is. If we are seeing a need to change it - perhaps it is a time. But I would try to work with ZK community to incorporate the fix into their next release.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Hi Konstantin Boudnik: This is not a vendor specific change, the change is picked from upstream (3.5 branch of zookeeper) . Poor wording from my side.

          The patch is removing a machine-specfic and gcc-specfic assembler statement and is replacing it with a gcc specific generic atomic instruction. That's really an improvement.

          Show
          oflebbe Olaf Flebbe added a comment - Hi Konstantin Boudnik : This is not a vendor specific change, the change is picked from upstream (3.5 branch of zookeeper) . Poor wording from my side. The patch is removing a machine-specfic and gcc-specfic assembler statement and is replacing it with a gcc specific generic atomic instruction. That's really an improvement.
          Hide
          cos Konstantin Boudnik added a comment -

          I don't like this. My main dislike is that we start meddling with Apache released software. I think someone wants a vendor-specific change in the stack's component - they need to work with the community in question. Bigtop releases shouldn't be used as a vehicle to make changes in the upstream.

          This is a slippery slope and we should use it with utmost caution: that's why I am generally against patching stuff in our releases.

          Show
          cos Konstantin Boudnik added a comment - I don't like this. My main dislike is that we start meddling with Apache released software. I think someone wants a vendor-specific change in the stack's component - they need to work with the community in question. Bigtop releases shouldn't be used as a vehicle to make changes in the upstream. This is a slippery slope and we should use it with utmost caution: that's why I am generally against patching stuff in our releases.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Use the gcc built in atomic operations rather assembler code

          Show
          oflebbe Olaf Flebbe added a comment - Use the gcc built in atomic operations rather assembler code

            People

            • Assignee:
              oflebbe Olaf Flebbe
              Reporter:
              oflebbe Olaf Flebbe
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development