From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 0EA6AA0554;
	Fri, 26 Aug 2022 10:58:18 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id A8B3340146;
	Fri, 26 Aug 2022 10:58:17 +0200 (CEST)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id 8B5EF40143;
 Fri, 26 Aug 2022 10:58:16 +0200 (CEST)
Content-class: urn:content-classes:message
Subject: The EAL is bloated
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Aug 2022 10:58:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D872B5@smartserver.smartshare.dk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The EAL is bloated
Thread-Index: Adi5KfpgSJqIOZpdQKS/8rrdAYg7Sg==
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Thomas Monjalon" <thomas@monjalon.net>,
 "David Marchand" <david.marchand@redhat.com>,
 "Ray Kinsella" <mdr@ashroe.eu>, "Jerin Jacob" <jerinj@marvell.com>,
 "Sunil Kumar Kori" <skori@marvell.com>,
 "Harry van Haaren" <harry.van.haaren@intel.com>, <dev@dpdk.org>
Cc: <techboard@dpdk.org>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

Dear all,

<rant>
The "Environment Abstraction Layer" is expanding far beyond its =
purpose...

It not only includes abstractions for the underlying CPU Arch and O/S, =
but also a bunch of generic utility functions. In an ideal world, these =
belong in a Utility library; but I can live with them staying in the EAL =
library.

However, since the Utility features are also considered part of the EAL =
library, some features get misclassified as Utilities and thus sneak =
into the EAL library, regardless that they are completely independent of =
the underlying CPU Arch and O/S. E.g.: Service Cores, Trace, and soon =
the Lcore Poll Busyness library.

The EAL is not a catch-all library, and we should not allow the EAL to =
grow like this!
</rant>

If this misbehavior doesn't stop naturally, I propose that adding any =
new feature to the EAL requires techboard approval.

-Morten