From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 708F9C11F68 for ; Fri, 2 Jul 2021 09:45:49 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id F3A5C61410 for ; Fri, 2 Jul 2021 09:45:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3A5C61410 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 132D941353; Fri, 2 Jul 2021 11:45:47 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id E850440686; Fri, 2 Jul 2021 11:45:44 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10032"; a="208658773" X-IronPort-AV: E=Sophos;i="5.83,316,1616482800"; d="scan'208";a="208658773" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2021 02:45:43 -0700 X-IronPort-AV: E=Sophos;i="5.83,316,1616482800"; d="scan'208";a="490206226" Received: from jkenneal-mobl.ger.corp.intel.com (HELO [10.213.205.74]) ([10.213.205.74]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2021 02:45:42 -0700 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , dpdk-techboard Cc: dpdk-dev References: <98CBD80474FA8B44BF855DF32C47DC35C618D2@smartserver.smartshare.dk> From: Ferruh Yigit X-User: ferruhy Message-ID: <932aacc8-2aea-e317-a5fe-2ba9cd735ab0@intel.com> Date: Fri, 2 Jul 2021 11:45:40 +0200 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C618D2@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-techboard] ABI/API stability towards drivers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 7/2/2021 10:00 AM, Morten Brørup wrote: > Regarding the ongoing ABI stability project, it is suggested to export driver interfaces as internal. > > What are we targeting regarding ABI and API stability towards drivers? > Hi Morten, It is about some device abstraction libraries, like cryptodev, exposing the internal driver to library interface to the application. And any change on them causing an unnecessary ABI break. So target is not drivers, but hide everything from application that only needs to be between lib and driver.