Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-5011

lustre_idl.h again does not compile in user space

Details

    • Bug
    • Resolution: Fixed
    • Major
    • Lustre 2.10.0
    • Lustre 2.4.0, Lustre 2.4.1, Lustre 2.5.0, Lustre 2.4.2, Lustre 2.5.1, Lustre 2.4.3
    • 3
    • 13871

    Description

      New ticket for the the recurring problem of lustre_idl.h not compiling in user-space. Conversation began in LU-1606, but we want to have a separate ticket for Lustre 2.6.0.

      Attachments

        Issue Links

          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. LU-4998 lustre_idl.h compilation regression from LU-2684

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. LU-5000 lustre_idl.h compilation regression from ORNL-10

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. LU-4997 lustre_idl.h compilation regression from LU-2743

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. LU-4999 lustre_idl.h compilation regression from LU-3569

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-5327 powerpc64 defines __u64 differently for kernel- and user-space

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. LU-5065 lfs should dogfood llapi

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. LU-6245 Untangle userland and kernel space support for libcfs

          • Major - Major loss of function.
          • Resolved
          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-5001 Backport needed to b2_4 of "LU-1606 idl: remove LASSERT/CLASSERT from lustre_idl.h"

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. LU-1606 lustre_idl.h does not compile in user-space

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. LU-6401 Untangle lustre userland and kernel headers

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Activity

            [LU-5011] lustre_idl.h again does not compile in user space
            spitzcor Cory Spitz added a comment -

            What does IDL even stand for?

            spitzcor Cory Spitz added a comment - What does IDL even stand for?
            simmonsja James A Simmons added a comment -

            With the work of LU-6401 I started to look closely at lustre_idl.h and I noticed its not really needed to user land except for wiretest and the wirechecker hack. It might be possible to make lustre_idl.h a kernel space only header.

            simmonsja James A Simmons added a comment - With the work of LU-6401 I started to look closely at lustre_idl.h and I noticed its not really needed to user land except for wiretest and the wirechecker hack. It might be possible to make lustre_idl.h a kernel space only header.
            simmonsja James A Simmons added a comment -

            That is excellent that some functions for liblustreapi has to be redone. We can move that code to liblustre_util.c and make it LGPL
            Please do send you WIP patch. I will gladly move it forward. I myself started to unwind the libcfs.h mess for the user land tools and utilities.

            simmonsja James A Simmons added a comment - That is excellent that some functions for liblustreapi has to be redone. We can move that code to liblustre_util.c and make it LGPL Please do send you WIP patch. I will gladly move it forward. I myself started to unwind the libcfs.h mess for the user land tools and utilities.
            adilger Andreas Dilger added a comment -

            When I was looking through this before the developer workshop I also saw this issue with kernel headers included into userspace. However, most of those headers are not actually needed for liblustreapi to work. I should send you my WIP patch for cleaning up some of those dependencies. In some cases it means reimplementing llapi functions to use different APIs (e.g. getting the Lustre version), but that's OK and maybe even desirable. In other cases, we just need to disentangle the headers, and only include the needed headers into userspace, rather than generic ones like "libcfs.h".

            adilger Andreas Dilger added a comment - When I was looking through this before the developer workshop I also saw this issue with kernel headers included into userspace. However, most of those headers are not actually needed for liblustreapi to work. I should send you my WIP patch for cleaning up some of those dependencies. In some cases it means reimplementing llapi functions to use different APIs (e.g. getting the Lustre version), but that's OK and maybe even desirable. In other cases, we just need to disentangle the headers, and only include the needed headers into userspace, rather than generic ones like "libcfs.h".
            simmonsja James A Simmons added a comment -

            I was surprised that liblustreapi still required lustre_idl.h. As I cleanup the libcfs header dependencies I noticed that the lustre headers relating to the utils is just a mess. Many lustre kernel headers are being pulled into the utils library. There is no clear separation of the layers and headers are placed either in lustre/include or lustre/include/lustre for the utils. This will need to be cleaned up.

            simmonsja James A Simmons added a comment - I was surprised that liblustreapi still required lustre_idl.h. As I cleanup the libcfs header dependencies I noticed that the lustre headers relating to the utils is just a mess. Many lustre kernel headers are being pulled into the utils library. There is no clear separation of the layers and headers are placed either in lustre/include or lustre/include/lustre for the utils. This will need to be cleaned up.
            jhammond John Hammond added a comment -

            > While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build.

            That's intentional. lustre_idl.h will not be packaged. llapi is the public interface.

            jhammond John Hammond added a comment - > While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build. That's intentional. lustre_idl.h will not be packaged. llapi is the public interface.
            simmonsja James A Simmons added a comment -

            While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build.

            simmonsja James A Simmons added a comment - While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build.
            morrone Christopher Morrone (Inactive) added a comment -

            Ah, great! Good riddance.

            The manual should have a note to users about lustre_idl.h's disappearance.

            morrone Christopher Morrone (Inactive) added a comment - Ah, great! Good riddance. The manual should have a note to users about lustre_idl.h's disappearance.
            sarah Sarah Liu added a comment -

            Hi Christopher,

            I didn't test lustre_idl.h because it has been removed
            http://review.whamcloud.com/#/c/10215

            [root@client-18 lustre]# ls
            liblustreapi.h ll_fiemap.h lustreapi.h lustre_user.h
            [root@client-18 lustre]# pwd
            /usr/include/lustre

            sarah Sarah Liu added a comment - Hi Christopher, I didn't test lustre_idl.h because it has been removed http://review.whamcloud.com/#/c/10215 [root@client-18 lustre] # ls liblustreapi.h ll_fiemap.h lustreapi.h lustre_user.h [root@client-18 lustre] # pwd /usr/include/lustre
            morrone Christopher Morrone (Inactive) added a comment -

            Wait, wait, wait. Why did you test lustreapi.h, lustre_user.h, and ll_fiemap.h when this ticket is very explicitly about lustre_idl.h?

            morrone Christopher Morrone (Inactive) added a comment - Wait, wait, wait. Why did you test lustreapi.h, lustre_user.h, and ll_fiemap.h when this ticket is very explicitly about lustre_idl.h?
            pjones Peter Jones added a comment -

            Thanks Sarah. This ticket will remain open as there are other subtasks still open but it sounds like the most critical tasks that were considered in scope for 2.6 are now complete so I am dropping that FixVersion and lowering the priority

            pjones Peter Jones added a comment - Thanks Sarah. This ticket will remain open as there are other subtasks still open but it sounds like the most critical tasks that were considered in scope for 2.6 are now complete so I am dropping that FixVersion and lowering the priority

            People

              jhammond John Hammond
              morrone Christopher Morrone (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: