From: Mike Holmes [mailto:mike.hol...@linaro.org] Sent: Tuesday, December 13, 2016 2:48 PM To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
On 13 December 2016 at 05:23, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> wrote: > -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Monday, December 12, 2016 4:52 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > > To allow other implementations of the helpers to exist such as those used > on the > Kalray system, we need to remove the hardwired Linux naming. This exists > in the > api, the implementation of the helper lib and the resulting library. Opaque thread helpers may very well exist with Linux (or Windows or Unix) specific helpers. Majority of the applications are developed against a defined operating system, not against an operating system abstraction layer. For example, a linux specific helper library (consuming and producing Linux types) would be valuable to many applications, may be even more valuable than the opaque thread helpers used by our validation suite. I agree, but the core reason for the helper lib is to support the tests, performance tests and examples to keep all the implementations together and tested uniformly in the reference implimentation. Anyone can use any OS specific code they want locally, we say helpers are not mandatory for that reason. I am fine if we have a new alternate repo or other obvious delineation for os specific help. However putting them in the main helper API makes portability impossible and we want to promote that first and allow for all performance optimizations to be done locally if needed. We do know that we have at least two OS'es actively using ODP. ---- HTML stops here ---- The point is that with Linux and ODP an application is directly portable to 90-95% of all networking SoCs. Also if an SoCs does not support Linux it's typically because of lacking HW features such as MMU, which again may restrict me to use it in the first place. So, typically 100% on the SoCs I'm interested in do support Linux and thus I do not need an opaque OS helper but a Linux helper. -Petri
