All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang at intel.com>
To: accel-config@lists.01.org
Subject: [Accel-config] Re: [PATCH] accel-config: Replicate driver error codes in idxd.h in library
Date: Mon, 19 Jul 2021 15:14:31 -0700	[thread overview]
Message-ID: <3975fb47-733a-f0ce-9c4d-d6e489de28c6@intel.com> (raw)
In-Reply-To: BYAPR11MB253521E78CC95C2916A7C27BEDE19@BYAPR11MB2535.namprd11.prod.outlook.com

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

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.

             reply	other threads:[~2021-07-19 22:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 22:14 Dave Jiang [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-07-20  0:24 [Accel-config] Re: [PATCH] accel-config: Replicate driver error codes in idxd.h in library Dave Jiang
2021-07-20  0:16 Thomas, Ramesh
2021-07-19 21:13 Thomas, Ramesh
2021-07-19 20:00 Dave Jiang
2021-07-19 19:35 Thomas, Ramesh
2021-07-19 17:50 Dave Jiang
2021-07-19 17:34 Thomas, Ramesh
2021-07-19 15:17 Dave Jiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3975fb47-733a-f0ce-9c4d-d6e489de28c6@intel.com \
    --to=accel-config@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.