Re: [dpdk-dev] [PATCH 00/12] update and simplify telemetry library.

[Thomas Monjalon <thomas@monjalon.net>]

02/04/2020 10:30, Morten Brørup:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Wednesday, April 1, 2020 6:16 PM
> > 
> > On Wed, Apr 01, 2020 at 05:42:21PM +0200, David Marchand wrote:
> > > Hello,
> > >
> > > On Thu, Mar 19, 2020 at 6:35 PM Ciara Power <ciara.power@intel.com>
> > wrote:
> > > >
> > > > This patchset extensively reworks the telemetry library adding new
> > > > functionality and simplifying much of the existing code, while
> > > > maintaining backward compatibility.
> 
> [...]
>  
> > > Is there a reason to keep a separate telemetry library rather than
> > > integrate this framework into EAL?
> > >
> > No reason this could not be done, however, since telemetry library is
> > already separate, and EAL is already pretty crowded, I think keeping
> > this
> > separate might lead to easier maintenance.
> > 
> > However, if people generally prefer it just merged into EAL, that can
> > be
> > done also.
> > 
> 
> No! EAL is the Environment Abstraction Layer. EAL should only provide the common abstraction interface for the different hardware/hypervisors and operating systems that may lie beneath the DPDK application, and nothing else.
> 
> If there is consensus that everyone absolutely needs some feature, which is not an abstraction of the underlying execution environment, it should be in a "Common" (or "Framework" or "Support") library instead.
> 
> EAL is already way too bloated.

I agree. We should move some features from EAL to a separate library.

> Take Service Cores for instance: It doesn't provide a shim for the underlying execution environment; it provides a process scheduling framework, which is optional for the DPDK application to use or not.
> 
> The same goes for the Trace library. Not a shim, but a framework library.
> 
> Logging is even worse: It logs to a file, but if it was truly an environment abstraction, it would log to the Event Log on Windows. In other words... Logging is not implemented as an environment abstraction, but at the preference of its implementer. I would consider it a core/framework library, not an EAL library.

Logging should be an OS abstraction, yes.
So logging must stay in EAL.