From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 6CDEB5A08 for ; Mon, 29 Dec 2014 17:17:45 +0100 (CET) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Y5d0k-0001Rn-9p; Mon, 29 Dec 2014 11:17:40 -0500 Date: Mon, 29 Dec 2014 11:17:35 -0500 From: Neil Horman To: Olivier MATZ Message-ID: <20141229161735.GB29258@localhost.localdomain> References: <1419521597-31978-1-git-send-email-rkerur@gmail.com> <54A11509.5050904@6wind.com> <20141229124723.GA27775@localhost.localdomain> <54A15420.2010401@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A15420.2010401@6wind.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/7] Move EAL common functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 16:17:45 -0000 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 >