What should we do while this is resolved to fix the compile issue? Should
I create an idxd.h with LGPL license?

On Mon, Jul 19, 2021 at 03:14:31PM -0700, Dave Jiang wrote:
> I just noticed that include/uapi/linux/ndctl.h is distributed as LGPL. I
> wonder if it's possible to change that given only we (Intel) has touched
> this file.
> 
> On 7/19/2021 2:13 PM, Thomas, Ramesh wrote:
> > Noticed driver idxd.h has GPL license. Library is LGPL and I remember
> > LGPL cannot use GPL code. Even if that is changed in newer drivers I am
> > not sure if there is any issue with older drivers.
> >
> > On Mon, Jul 19, 2021 at 01:00:46PM -0700, Dave Jiang wrote:
> >> On 7/19/2021 12:35 PM, Thomas, Ramesh wrote:
> >>> On Mon, Jul 19, 2021 at 10:50:09AM -0700, Dave Jiang wrote:
> >>>> On 7/19/2021 10:34 AM, Thomas, Ramesh wrote:
> >>>>> I think copying will have the problem of compiler picking different
> >>>>> ones. Library may use the copied version while the app may get the one
> >>>>> in /usr/include. Do you think defining new constants would be safer?
> >>>> I think instead of pulling the /usr/include version we just depend on
> >>>> the copied version exclusively. Then we will have 1 less dependency and
> >>>> compile correctly always.
> >>> I was also concerned about user apps including the /user/include idxd.h.
> >>> Even in libaccel we would need to make assumptions that the constants
> >>> used will not diverge from the one driver is using. Since the issue is
> >>> only about some constants like the sw cmd_status which is not available
> >>> in older idxd.h, I think it is better to define them separately and
> >>> privately for the library.
> >>>
> >> User ABI is considered constant for Linux and if we are changing it,
> >> there would be ways to provide backward compatibility. I think making
> >> copy of header should be safe. That is why ndctl does that.