DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/7] Move EAL common functions
Date: Mon, 29 Dec 2014 11:17:35 -0500
Message-ID: <20141229161735.GB29258@localhost.localdomain> (raw)
In-Reply-To: <54A15420.2010401@6wind.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
> 

  reply	other threads:[~2014-12-29 16:17 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-25 15:33 Ravi Kerur
2014-12-25 15:33 ` [dpdk-dev] [PATCH 1/7] Fix rte_is_power_of_2 Ravi Kerur
2014-12-25 17:21   ` Neil Horman
2014-12-25 18:54     ` Ravi Kerur
2014-12-25 15:33 ` [dpdk-dev] [PATCH 2/7] Move EAL common functions Ravi Kerur
2014-12-25 17:30   ` Neil Horman
2014-12-25 19:23     ` Ravi Kerur
2014-12-26 14:40       ` Neil Horman
2014-12-26 15:28         ` Ravi Kerur
2015-01-05  9:40           ` Thomas Monjalon
2014-12-25 15:33 ` [dpdk-dev] [PATCH 3/7] " Ravi Kerur
2014-12-25 17:41   ` Neil Horman
2014-12-25 19:13     ` Ravi Kerur
2014-12-26 14:40       ` Neil Horman
2014-12-25 15:33 ` [dpdk-dev] [PATCH 4/7] " Ravi Kerur
2014-12-25 17:44   ` Neil Horman
2014-12-25 19:17     ` Ravi Kerur
2014-12-26 14:42       ` Neil Horman
2014-12-26 15:30         ` Ravi Kerur
2015-01-05 15:59   ` Thomas Monjalon
2015-01-05 16:21     ` Ravi Kerur
2015-01-05 18:56     ` Ravi Kerur
2015-01-05 20:38       ` Thomas Monjalon
2015-01-06 17:35         ` Ravi Kerur
2014-12-25 15:33 ` [dpdk-dev] [PATCH 5/7] " Ravi Kerur
2015-01-05 15:32   ` Thomas Monjalon
2014-12-25 15:33 ` [dpdk-dev] [PATCH 6/7] " Ravi Kerur
2015-01-05 15:49   ` Thomas Monjalon
2014-12-25 15:33 ` [dpdk-dev] [PATCH 7/7] " Ravi Kerur
2014-12-25 17:46   ` Neil Horman
2014-12-25 19:22     ` Ravi Kerur
2014-12-26 14:44       ` Neil Horman
2014-12-26 15:28         ` Ravi Kerur
2014-12-29  8:47 ` [dpdk-dev] [PATCH 0/7] " Olivier MATZ
2014-12-29 12:47   ` Neil Horman
2014-12-29 13:16     ` Olivier MATZ
2014-12-29 16:17       ` Neil Horman [this message]
2014-12-29 18:43       ` Ravi Kerur
2015-01-04 23:10         ` Ravi Kerur
2015-01-05 12:24           ` Bruce Richardson
2015-01-09  9:50             ` Olivier MATZ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141229161735.GB29258@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git