On Wed, Aug 9, 2023 at 3:36 PM Bruce Richardson <bruce.richard...@intel.com> wrote: > > There is a general desire to reduce the size and scope of EAL. To this > end, this patchset makes a (very) small step in that direction by taking > the logging functionality out of EAL and putting it into its own library > that can be built and maintained separately. > > As with the first RFC for this, the main obstacle is the "fnmatch" > function which is needed by both EAL and the new log function when > building on windows. While the function cannot stay in EAL - or we would > have a circular dependency, moving it to a new library or just putting > it in the log library have the disadvantages that it then "leaks" into > the public namespace without an rte_prefix, which could cause issues. > Since only a single function is involved, subsequent versions take a > different approach to v1, and just moves the offending function to be a > static function in a header file. This allows use by multiple libs > without conflicting names or making it public. > > The other complication, as explained in v1 RFC was that of multiple > implementations for different OS's. This is solved here in the same > way as v1, by including the OS in the name and having meson pick the > correct file for each build. Since only one file is involved, there > seemed little need for replicating EAL's separate subdirectories > per-OS.
Series applied, thanks Bruce for this first step. As mentionned during the maintainers weekly call yesterday, this is only a first "easy" step but, thinking of next steps, more splitting may not be that easy. At least, on the libabigail topic, as we need the ABI check to handle libraries splits, a new feature has been cooked in (not yet released) 2.4 libabigail. https://sourceware.org/git/?p=libabigail.git;a=commitdiff;h=0b338dfaf690993e123b6433201b3a8b8204d662 Hopefully, we will have a libabigail release available by the time we start the v24.03 release (and re-enable ABI checks). -- David Marchand
