From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 71262A0537; Wed, 5 Feb 2020 07:16:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 87E041C02E; Wed, 5 Feb 2020 07:16:17 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 127862C12 for ; Wed, 5 Feb 2020 07:16:15 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0156F7OJ030679; Tue, 4 Feb 2020 22:16:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=KumeW6LmVwX0tD/hZx5GkdG2GDwc84Ok5sYFaDFHwkk=; b=ovAS+BQkY8u5QrM+q2XMawO1BlNqtmhgz9M9Ovgy17LRisTsmjlMEjA00ium03lJ2Ip2 ievyiQFd+r5X64YXRRY8J4bmRx8B93auXeSEjXfgDDhNRi2Wb4Wr4Kya17a3iy9Ij2vB rn2/WuZdv0zqOaTMENdyKcdYGL2Ze4tZJ0iSbA3OHNJHxblVcO0TiIMmLShxqR1kwx5f 0dkqVe6/QZAvFEYwg6vjQqf1ol8FUTSGvHdrpFJHI7QqwiMvPhqRUQspKp9To+zp2eI6 Kpv2iH1+DLfw4c8aTv+6CH5fG7xunqQMRxvcb+fi9y7KTBFmHERn/GS9k+5e1uH2qK/M Cw== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2xyhmt9e4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 22:16:08 -0800 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Feb 2020 22:16:07 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 4 Feb 2020 22:16:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dl3fcmzFRWgH8Lr3lDZyAC0nq1lY2xuOpxffJ9LULP/Y/57QTVkO8jOxhWmgXe/qSfdgpQesV2JUzpHQZUJvPMWzHzVuAKd2jf/gnCY0ByE7C1okva/1dOz2mUslNxkBdt314KbTqtLm6jeAA4HqL0vPoKTCz1KWSLvyOp0Mj+Ke1bK73AxEnYBXoBU3weLxHfwrA4+43jwpJa3oMsJDe66GAdJ2ftzTeeB5ODNZUVW8mgmjeIHg0GbuD747ky5BVuKKut5DAkogsTHl9qtBGYahuA384rE5Hcq7GRasB+0/FsUnGBEWw9ZKSY4ooO9ZIefaJ6kYn5NtTfXhxZ8I0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KumeW6LmVwX0tD/hZx5GkdG2GDwc84Ok5sYFaDFHwkk=; b=XLyO42485SrFnsflyGaz8duUcLkO78rESKqpwymtvaQCLk0VWjlLWZUIlYnnYytGbU+vBrAFnTWbx3avMNZYL+Ns9w/McOAk7TZ0B9Yw3oYKZDoJf6ivIeR+JpAdNfp6a6lhEuXGt5xC/AQzvbDbz0oLbncbcfXpPS7GtQWtVJLNVwJaE3UXGnUsH1f8w8oOJJLFsGrPgN5khgWYcQREiuyZtFrJhaU6bYQRnJy1lcxn41Jn4eXPoKH/g/4jTmpLmEs95jf8a1BsK+rMM243YGkkT15M3Tdq3Yjwbb9IUgp4fyJg4p/qG2Ghxxhl12IP5Py8kZZ9yZwSaj0f2sWikw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KumeW6LmVwX0tD/hZx5GkdG2GDwc84Ok5sYFaDFHwkk=; b=nXnRcRmAX+rFrOKur2ta8bLpd0kDMcgflF6VNGb3zegXUOmXHMuBahi9au8dRlbKa9M7y1l8VuKAv0X14GU0VptrqGTEmhuIrWANAkZ7Tdo4/m19q4Gsy2A9yYvYKbAdbtWnNk9R0y3VqIhsvSWiM6LRtZi4MY8n+ByYXdnHYCc= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2704.namprd18.prod.outlook.com (20.178.255.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Wed, 5 Feb 2020 06:16:05 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::e48d:494:fc46:3572]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::e48d:494:fc46:3572%7]) with mapi id 15.20.2686.035; Wed, 5 Feb 2020 06:16:05 +0000 From: Anoob Joseph To: Neil Horman , Akhil Goyal , "Trahe, Fiona" CC: Thomas Monjalon , Ferruh Yigit , "Ananyev, Konstantin" , "Trahe, Fiona" , "dev@dpdk.org" , David Marchand , "Kusztal, ArkadiuszX" , "Richardson, Bruce" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "aconole@redhat.com" , "bluca@debian.org" , "ktraynor@redhat.com" Thread-Topic: [EXT] Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks Thread-Index: AQHV20ZcWGV3yvNFtUini8bgLlPou6gLmToAgAB8XhA= Date: Wed, 5 Feb 2020 06:16:05 +0000 Message-ID: References: <20191220152058.10739-1-david.marchand@redhat.com> <78e8ecf2-2239-897e-e34c-aee7227f3d42@intel.com> <3830195.LM0AJKV5NW@xps> <20200204221020.GD13754@hmswarspite.think-freely.org> In-Reply-To: <20200204221020.GD13754@hmswarspite.think-freely.org> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [111.125.192.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a820265-af5a-4129-3668-08d7aa02e235 x-ms-traffictypediagnostic: MN2PR18MB2704: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(376002)(346002)(136003)(39850400004)(199004)(189003)(30864003)(2906002)(86362001)(71200400001)(478600001)(33656002)(4326008)(55016002)(5660300002)(52536014)(9686003)(66476007)(66556008)(64756008)(66446008)(66946007)(76116006)(110136005)(186003)(316002)(8676002)(26005)(55236004)(53546011)(54906003)(6506007)(7416002)(81156014)(8936002)(7696005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2704; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5sFDiZydyoFt9tqpIGNLq5aqESiX9y6ByxYfpfiEClldHAgnJvlCHmop5uumL/HrCzVKNcu+IlcthCawD23j901fTMNODAXxN2nB7A50woLGCAh35JG9jQNdCLfVaPN1EDhYRbUShrT8Oc0XPSKsrYb/XAmnMoAwQzl49+wgtaoI8qQjggIxASTvezd9GwJIOAhySihy6+hJMjrEo/hMx7wgdhRP1L+igVoA80t0G8ZI0V1JJA05560T2O6lMRIqDeB1u0+TKH4SgOLPuzs+qHGvxeO5FvHzTybhzsa83l7PVeKAkiBhe4dz/Ok7ivLPyMD25EIxzwW/fJddcszw0KYvM/xTS6xSN+m4IZcJIcltmF6VoA7ydZhW/c63rGZ0KYzI/eWf1IR7QfzVj7SlZaUfS62167cmGhGtJGIiOqPCwdDL5TOJQGvVLTvFhSJc x-ms-exchange-antispam-messagedata: DUlj3sFs7i2LhJG7CmiYpSKtg5hio4T6zqswozQND3tDaOIqm1Kg+RXRrSxZ64EOzECxqvjJGRo3gg1lEKozJciej7TwaK1ytnFZ/jHqfAYUlHVL0uuczr8/oSw4R2upKE5oNEa73zlD2Gg4yNL4kQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1a820265-af5a-4129-3668-08d7aa02e235 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 06:16:05.7029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fFyIL3+SiMR/L2pOWTYukIP3/sDRgh5OqYvOVb0WgCJkgZV740CrTwE6CA5OKcXBRqUfhTI+Cj81Xg3le5Tm0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2704 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-05_01:2020-02-04, 2020-02-05 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 4/4] add ABI checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hi Akhil, Neil, Fiona Sorry for the late response. I want to propose a new change in line with wh= at you folks had proposed. May be we can treat the new features EXPERIMENTAL until a new stable releas= e. enum rte_crypto_aead_algorithm { RTE_CRYPTO_AEAD_AES_CCM =3D 1, /**< AES algorithm in CCM mode. */ RTE_CRYPTO_AEAD_AES_GCM, /**< AES algorithm in GCM mode. */ RTE_CRYPTO_AEAD_LIST_END, /**< List end for stable */ /** EXPERIMENTAL */ RTE_CRYPTO_AEAD_CHACHA20_POLY1305, /**< Chacha20 cipher with poly1305 authenticator */ RTE_CRYPTO_AEAD_LIST_END_EXPERIMENTAL /**< List end */ }; And then introduce an experimental API, const struct rte_cryptodev_capabilities * rte_cryptodev_get_exp_capabilites(uint8_t dev_id); The PMD owner is expected to add new capabilities (only new ones) to this o= ne until the new feature is deemed stable (ie, in one of the next stable re= leases). We don't expect users to change their API/ABI. For applications us= ing EXPERIMENTAL is allowed to use the above capabilities to get the EXPERI= MENTAL features. This does involve moving around code in PMD when one feature is added, but = that's the risk PMD owner is taking by upstreaming as EXPERIMENTAL and not = in stable release. Thanks, Anoob > -----Original Message----- > From: Neil Horman > Sent: Wednesday, February 5, 2020 3:40 AM > To: Akhil Goyal > Cc: Thomas Monjalon ; Ferruh Yigit > ; Ananyev, Konstantin > ; Trahe, Fiona ; > dev@dpdk.org; David Marchand ; Anoob Joseph > ; Kusztal, ArkadiuszX ; > Richardson, Bruce ; Mcnamara, John > ; dodji@seketeli.net; Andrew Rybchenko > ; aconole@redhat.com; bluca@debian.org; > ktraynor@redhat.com > Subject: [EXT] Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks >=20 > External Email >=20 > ---------------------------------------------------------------------- > On Tue, Feb 04, 2020 at 10:32:01AM +0000, Akhil Goyal wrote: > > > > > > > > 04/02/2020 11:16, Akhil Goyal: > > > > Hi, > > > > > On 2/3/2020 5:09 PM, Thomas Monjalon wrote: > > > > > > 03/02/2020 10:30, Ferruh Yigit: > > > > > >> On 2/2/2020 2:41 PM, Ananyev, Konstantin wrote: > > > > > >>> 02/02/2020 14:05, Thomas Monjalon: > > > > > >>>> 31/01/2020 15:16, Trahe, Fiona: > > > > > >>>>> On 1/30/2020 8:18 PM, Thomas Monjalon wrote: > > > > > >>>>>> 30/01/2020 17:09, Ferruh Yigit: > > > > > >>>>>>> On 1/29/2020 8:13 PM, Akhil Goyal wrote: > > > > > >>>>>>>> > > > > > >>>>>>>> I believe these enums will be used only in case of ASYM > > > > > >>>>>>>> case which > > > is > > > > > experimental. > > > > > >>>>>>> > > > > > >>>>>>> Independent from being experiment and not, this > > > > > >>>>>>> shouldn't be a > > > > > problem, I think > > > > > >>>>>>> this is a false positive. > > > > > >>>>>>> > > > > > >>>>>>> The ABI break can happen when a struct has been shared > > > > > >>>>>>> between > > > the > > > > > application > > > > > >>>>>>> and the library (DPDK) and the layout of that memory > > > > > >>>>>>> know > > > differently > > > > > by > > > > > >>>>>>> application and the library. > > > > > >>>>>>> > > > > > >>>>>>> Here in all cases, there is no layout/size change. > > > > > >>>>>>> > > > > > >>>>>>> As to the value changes of the enums, since application > > > > > >>>>>>> compiled > > > with > > > > > old DPDK, > > > > > >>>>>>> it will know only up to '6', 7 and more means invalid to > > > > > >>>>>>> the > > > application. > > > > > So it > > > > > >>>>>>> won't send these values also it should ignore these > > > > > >>>>>>> values from > > > library. > > > > > Only > > > > > >>>>>>> consequence is old application won't able to use new > > > > > >>>>>>> features > > > those > > > > > new enums > > > > > >>>>>>> provide but that is expected/normal. > > > > > >>>>>> > > > > > >>>>>> If library give higher value than expected by the > > > > > >>>>>> application, if the application uses this value as array > > > > > >>>>>> index, there can be an access out of bounds. > > > > > >>>>> > > > > > >>>>> [Fiona] All asymmetric APIs are experimental so above > > > > > >>>>> shouldn't be a > > > > > problem. > > > > > >>>>> But for the same issue with sym crypto below, I believe > > > > > >>>>> Ferruh's > > > > > explanation makes > > > > > >>>>> sense and I don't see how there can be an API breakage. > > > > > >>>>> So if an application hasn't compiled against the new lib > > > > > >>>>> it will be still > > > using > > > > > the old value > > > > > >>>>> which will be within bounds. If it's picking up the higher > > > > > >>>>> new value > > > from > > > > > the lib it must > > > > > >>>>> have been compiled against the lib so shouldn't have proble= ms. > > > > > >>>> > > > > > >>>> You say there is no ABI issue because the application will > > > > > >>>> be re- > > > compiled > > > > > >>>> for the updated library. Indeed, compilation fixes compatibi= lity > issues. > > > > > >>>> But this is not relevant for ABI compatibility. > > > > > >>>> ABI compatibility means we can upgrade the library without > > > recompiling > > > > > >>>> the application and it must work. > > > > > >>>> You think it is a false positive because you assume the > > > > > >>>> application "picks" the new value. I think you miss the > > > > > >>>> case where the new value is returned by a function in the up= graded > library. > > > > > >>>> > > > > > >>>>> There are also no structs on the API which contain arrays > > > > > >>>>> using this for sizing, so I don't see an opportunity for > > > > > >>>>> an appl to have a mismatch in memory addresses. > > > > > >>>> > > > > > >>>> Let me demonstrate where the API may "use" the new value > > > > > >>>> RTE_CRYPTO_AEAD_CHACHA20_POLY1305 and how it impacts the > > > > > application. > > > > > >>>> > > > > > >>>> Once upon a time a DPDK application counting the number of > > > > > >>>> devices supporting each AEAD algo (in order to find the best > supported algo). > > > > > >>>> It is done in an array indexed by algo id: > > > > > >>>> int aead_dev_count[RTE_CRYPTO_AEAD_LIST_END]; > > > > > >>>> The application is compiled with DPDK 19.11, where > > > > > >>>> RTE_CRYPTO_AEAD_LIST_END =3D 3. > > > > > >>>> So the size of the application array aead_dev_count is 3. > > > > > >>>> This binary is run with DPDK 20.02, where > > > > > >>>> RTE_CRYPTO_AEAD_CHACHA20_POLY1305 =3D 3. > > > > > >>>> When calling rte_cryptodev_info_get() on a device QAT_GEN3, > > > > > >>>> rte_cryptodev_info.capabilities.sym.aead.algo is set to > > > > > >>>> RTE_CRYPTO_AEAD_CHACHA20_POLY1305 (=3D 3). > > > > > >>>> The application uses this value: > > > > > >>>> ++ aead_dev_count[info.capabilities.sym.aead.algo]; > > > > > >>>> The application is crashing because of out of bound access. > > > > > >>> > > > > > >>> I'd say this is an example of bad written app. > > > > > >>> It probably should check that returned by library value > > > > > >>> doesn't exceed its internal array size. > > > > > >> > > > > > >> +1 > > > > > >> > > > > > >> Application should ignore values >=3D MAX. > > > > > > > > > > > > Of course, blaming the API user is a lot easier than looking at= the API. > > > > > > Here the API has RTE_CRYPTO_AEAD_LIST_END which can be > > > > > > understood as the max value for the application. > > > > > > Value ranges are part of the ABI compatibility contract. > > > > > > It seems you expect the application developer to be aware that > > > > > > DPDK could return a higher value, so the application should > > > > > > check every enum values after calling an API. CRAZY. > > > > > > > > > > > > When we decide to announce an ABI compatibility and do some > > > > > > marketing, everyone is OK. But when we need to really make our > > > > > > ABI compatible, I see little or no effort. DISAPPOINTING. > > > > > > > > > > This is not to blame the user or to do less work, this is more > > > > > sane approach that library provides the _END/_MAX value and > > > > > application uses it as valid > > > range > > > > > check. > > > > > > > > > > > > > > > > >> Do you suggest we don't extend any enum or define between ABI > > > breakage > > > > > releases > > > > > >> to be sure bad written applications not affected? > > > > > > > > > > > > I suggest we must consider not breaking any assumption made on = the > API. > > > > > > Here we are breaking the enum range because nothing mentions > > > _LIST_END > > > > > > is not really the absolute end of the enum. > > > > > > The solution is to make the change below in 20.02 + backport in > 19.11.1: > > > > > > > > > > > > - _LIST_END > > > > > > + _LIST_END, /* an ABI-compatible version may increase this > > > > > > + value */ _LIST_MAX =3D _LIST_END + 42 /* room for > > > > > > + ABI-compatible additions */ > > > > > > }; > > > > > > > > > > > > > > > > What is the point of "_LIST_MAX" here? > > > > > > > > > > Application should know the "_LIST_END" of when it has been > > > > > compiled for > > > the > > > > > valid range check. Next time it is compiled "_LIST_END" may be > > > > > different > > > value > > > > > but same logic applies. > > > > > > > > > > When "_LIST_END" is missing, application can't protect itself, > > > > > in that case library should send only the values application > > > > > knows when it is compiled, > > > this > > > > > means either we can't extend our enum/defines until next ABI > > > > > breakage, or > > > we > > > > > need to do ABI versioning to the functions that returns an enum > > > > > each time > > > enum > > > > > value extended. > > > > > > > > > > I believe it is saner to provide _END/_MAX values to the applicat= ion to > use. > > > And > > > > > if required comment them to clarify the expected usage. > > > > > > > > > > But in above suggestion application can't use or rely on > > > > > "_LIST_MAX", it > > > doesn't > > > > > mean anything to application. > > > > > > > > > > > > > Can we have something like > > > > enum rte_crypto_aead_algorithm { > > > > RTE_CRYPTO_AEAD_AES_CCM =3D 1, > > > > /**< AES algorithm in CCM mode. */ > > > > RTE_CRYPTO_AEAD_AES_GCM, > > > > /**< AES algorithm in GCM mode. */ > > > > RTE_CRYPTO_AEAD_LIST_END, > > > > /**< List end for 19.11 ABI compatibility */ > > > > RTE_CRYPTO_AEAD_CHACHA20_POLY1305, > > > > /**< Chacha20 cipher with poly1305 authenticator */ > > > > RTE_CRYPTO_AEAD_LIST_END_2011 > > > > /**< List end for 20.11 ABI compatibility */ }; > > > > > > > > And in 20.11 release we alter the RTE_CRYPTO_AEAD_LIST_END to the > > > > end > > > and remove RTE_CRYPTO_AEAD_LIST_END_2011 > > > > > > > > I believe it will be ok for any application which need to use the > > > > chacha poly > > > assume that this algo is > > > > Experimental and will move to formal list in 20.11. This can be > > > > documented in > > > the documentation. > > > > I believe there is no way to add a new enum as experimental so > > > > far. This way > > > we can formalize this > > > > requirement as well. > > > > > > > > I believe this way effect of ABI breakage will be nullified. > > > > > > This is a possibility in the (a) proposal. > > > But it breaks API (and ABI) because a high value is returned while > > > not expected by the application. > > > > > > I guess ABI and release maintainers will vote no to such breakage. > > > Note: I vote no. > > > > > > > If that is the case, I would say we should go with b). > > > > Versioned APIs does not look good and adds more confusion. > > > What makes you say that? >=20 > Versioned APIs are the way you maintain backward compatibility. >=20 > If a library doesn't use versioned API's, then they either: >=20 > 1) break frequently, causing application headaches > 2) have APIS that are so mature, strictly defined, and small, they never = change > anyway > 3) go to the trouble of creating compat libs for as far back as they need= to > support >=20 > DPDK doesn't yet have a mature, stable API, so we have to do (1) or (2). = (1) has > already been declared a bad idea, because application developers and dist= ros > have declared a desire for backwards compatibility. We could go with (3) > instead of ABI versioning, but between compat libs and versioning, the la= tter is > the much less difficult way to handle that. >=20 > Neil