On 3 February 2017 at 14:11, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>
>
>> -----Original Message-----
>> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
>> Sent: Friday, February 03, 2017 2:29 PM
>> To: Petri Savolainen <petri.savolai...@linaro.org>
>> Cc: LNG ODP Mailman List <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>> On 3 February 2017 at 12:23, Petri Savolainen
>> <petri.savolai...@linaro.org> wrote:
>> > There's no platform specific helpers. Helpers may depend on
>> > Linux and make it easier to do common series of Linux system
>> > calls. These kind of helpers are grouped into helper/linux
>> > directory.
>>
>> This is getting really confusing to me! Haven't we defined a
>> "platform" as being a couple {OS, HW}? That is any change in this
>> couple makes a new platform...
>> If we hold to this definition, then linux-helpers becomes platform
>> helpers...
>> Now, my humble opinion is that no-one is using these linux-only
>> helpers and no one ever will unless to enforce their usage by example
>> that people could copy/paste: why would a programmer want to replace a
>> well known linux system call by an ODP helper call? to save a for
>> loop?.
>> We are hitting the same usual problem of lack of proper definition for
>> things, but in this special case, my proposal is called "deletion".
>> :-)
>>
>> Christophe
>
> This is needed by OFP, for example.
>
> The current ODP master (after v1.13) moved things backwards as linux helper
> (which create e.g. pthreads and call odp_local_init / _term() for those) was
> renamed as "linux-generic helper". That would need OFP to expose
> "helper/linux-generic/..." in its Makefiles, which is both ugly and wrong (in
> the sense that helper code is part application code, not implementation code).
I am really getting confused here...
There are two sorts of things today in the helper (regarding ODPthread
creation):
1)odph_odpthreads_create() familly of functions abstracts the ODP
thread creation, i.e. will create OPD threads. Whether that is a
pthread or linux process or anything else under the hood is hidden: It
just creates a set of ODPthreads. (for those implementation which
(should) supports different implemenation, a helper flag can be used
to select what should be done)
2)linux specific functions creating pthreads or processes. If the
application uses those, the application is definitively binding itself
to linux and is then using these functions instead of calling
pthread_create() or fork() directely.
>From Mikes comment, I understand that OFP is using functions from the
second set. Do they have any reason for doing that? Possibly, if they
share data allocated after the thread creatiion, not using
odp_shm_reserve().
If an application really binds itseft to linux, I don't see anything
wrong if it is reflected in its Makefile ("helper/linux-generic/...").
If OFP does not require any specific type of ODP thread (they just
want concurrency but don't care how this is achieved) , then they
should be using function from the first set.
The Second set of function is not of much value in my eyes: They do
not provide any kind of abstraction, but just some kind of shortcut
avoiding a few things round fork() or pthread_create().
When I see the confusion that they generate, compared to the little
gain they provide (avoiding to write about 100lines of code), I still
feel those function should be part of the application. Most programmer
knows much more about pthread_create() and fork(), and the price
rewritting the little piece of code will probably been seen as lower
than learning the helper API.
The role of the helpers becomes then clearer: Abstracting thing that
can be done differentely on different platform.
Christophe
>
> -Petri
>
>
>
>
>
