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

[Ravi Kerur <rkerur@gmail.com>]

Hi,

I plan to work on this and would like to know if I need consider anything
else other than mentioned in the email by Olivier/Neil i.e.go with 2
directories

common-os/generic-os
common-posix

under librte_eal directory and move relevant files accordingly.

Thanks,
Ravi

On Mon, Dec 29, 2014 at 10:43 AM, Ravi Kerur <rkerur@gmail.com> wrote:

> Thanks Olivier and Neil. I will make a note on this and will work on it
> after initial common code movement is completed.
>
>
> On Mon, Dec 29, 2014 at 5:16 AM, Olivier MATZ <olivier.matz@6wind.com>
> 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).
>>
>> 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)
>>
>> 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.
>>
>> Regards,
>> Olivier
>>
>
>