02/04/2020 10:30, Morten Brørup: > > From: dev [mailto:dev-boun...@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.po...@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.
