Re: [dpdk-dev] [PATCH 0/7] Move EAL common functions

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, Dec 29, 2014 at 02:16:16PM +0100, Olivier MATZ wrote:
> Hi Neil,
> 
> On 12/29/2014 01:47 PM, Neil Horman wrote:
> > On Mon, Dec 29, 2014 at 09:47:05AM +0100, Olivier MATZ wrote:
> >> Trying to factorize the common code goes in the good direction.
> >>
> >> However I'm wondering if "common" is the proper place. Initially,
> >> the common directory was for code common to linuxapp and baremetal.
> >> Now that baremetal does not exist anymore, a lot of code is common
> >> to the 2 OSes that are supported (linux and FreeBSD).
> >>
> >> What about moving this code in "common-posix" instead?
> >> It would let the door open for future ports (Windows? or any
> >> other real time OS? Or back in baremetal?).
> >>
> > Posix doesn't make sense IMO, in that a large segment of the functions embodied
> > in the common directory have nothing to do with posix API's, and are simply just
> > useful functions that have not OS specific dependency (the entire
> > eal_common_memory.c file for example, to name just one).  
> > 
> > If you wanted to rename the directory, I would say generic-os would be more
> > appropriate.
> 
> That's probably right for most of the code in the patch. I just wanted
> to point out that "common" is sometimes a bit vague (common to archs,
> common to OSes, common to all).
> 
Agreed, common isn't explicitly common to everything
> From a quick look, these 2 files could be concerned and could go to a
> common-posix directory:
> - eal.c (use fopen/ftruncate/fcntl/mmap/...)
> - eal_thread.c (use pipe/read/write)
> 
Thats what they use, sure, but they don't export any POSIX mapped API, nor are
they guaranteed to only use POSIX library calls in the future (e.g. eal.c
exports functions like eal_parse_sysfs_value, which is completely unrelated to
POSIX, and may be implemented using zzip_file_read, though I wouldn't recommend
it :)).  Point being naming the directory common-posix, is not a descriptor of
either its exported API, nor a guarantee of its internal implementation.  I
would be more comfortable with something that is descriptive of the fact that
this code exports an API that is common to all operating systems (something like
generic-eal).  If the implementation of a given function in common isn't
supported on a newly added operating system, then we need to either remove the
function from the common directory and do specific implementations of it for
each os, or develop an override mechanism (something like marking the common
function as weak, and implementing an override version in any OS that doesn't
support its implementation.

> There's no urgency to do that now and maybe we should wait it's really
> needed. I was just seizing the opportunity as the code is moved.
> 
No, no urgency, but its been my experience that this sort of work doesn't get
done unless theres a motivator to make it so.  We have a contributor here that
is willing to do the work, so this seems like an opportune time to suggest stuff
like this.  If he doesn't want to do it, so be it, this collapsing is definately
better that what is there now, but if he's willing, I think this would be
another great step forward.
Neil

> Regards,
> Olivier
>