Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Maxim Uvarov]

ok, thanks.

On 17 February 2017 at 12:39, 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
> Maxim
> > Uvarov
> > Sent: Thursday, February 16, 2017 10:55 PM
> > To: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> > linux helpers
> >
> > On 02/16/17 11:51, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Savolainen, Petri (Nokia - FI/Espoo)
> > >> Sent: Monday, February 13, 2017 5:10 PM
> > >> To: 'Mike Holmes' <mike.hol...@linaro.org>
> > >> Cc: lng-odp <lng-odp@lists.linaro.org>
> > >> Subject: RE: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> > to
> > >> linux helpers
> > >>
> > >>
> > >>
> > >> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> > >> Sent: Monday, February 13, 2017 5:02 PM
> > >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> > >> labs.com>
> > >> Cc: lng-odp <lng-odp@lists.linaro.org>
> > >> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> > to
> > >> linux helpers
> > >>
> > >>
> > >>
> > >> On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo)
> > >> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
> > >>
> > >>
> > >> From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
> > >> Sent: Friday, February 10, 2017 5:02 PM
> > >> To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
> > >> Cc: lng-odp <mailto: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 06:23, Petri Savolainen
> > >> <mailto:mailto: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.
> > >>
> > >> Use --enable-helper-linux configuration option to enable
> > >> support for Linux helpers.
> > >>
> > >> Signed-off-by: Petri Savolainen
> > >> <mailto:mailto:petri.savolai...@linaro.org>
> > >>
> > >> Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>
> > >>
> > >> required 3 way apply
> > >>
> > >>
> > >>
> > >> This should be merged. It moves linux dependent helper code under
> linux
> > >> folder. If there would be helper code dependent on some other OS, that
> > >> would go to their own helper/OS_foo/ folder. All Linux based ODP
> > >> implementations can run this helper code - there is no need to have N
> > >> different linux helpers for N different Linux based implementations.
> > >>
> > >>
> > >> Also, the build is currently broken in master for
> --enable-helper-extn.
> > >> E.g. OFP cannot be built against it.
> > >>
> > >> This is not broken IMHO, it is by design, OFP depends on the helpers,
> > we
> > >> need helpers to either be support for apps that we maintain and don't
> > use
> > >> (current case) or we enforce  OFP and others to use the abstract API
> > that
> > >> all our own executable use. Maintaining code we don't use is
> dangerous,
> > >> you should have to choose to do it, but I like the rename, that is
> fine
> > >> and is progress, hence the review.
> > >>
> > >> I think splitting out all of all the executables  will make this much
> > >> cleaner.
> > >> All ODP upstream executables will use the abstract API and be portable
> > to
> > >> any platform and OS. Meanwhile the odp-Linux repo can have a Linux
> > >> specific apis such as the legacy one OFP is using and that is just
> that
> > >> implementations choice, as we have said there is no requirement to use
> > >> helpers, or linux, and OFP might want to att

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim
> Uvarov
> Sent: Thursday, February 16, 2017 10:55 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 02/16/17 11:51, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: Savolainen, Petri (Nokia - FI/Espoo)
> >> Sent: Monday, February 13, 2017 5:10 PM
> >> To: 'Mike Holmes' <mike.hol...@linaro.org>
> >> Cc: lng-odp <lng-odp@lists.linaro.org>
> >> Subject: RE: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to
> >> linux helpers
> >>
> >>
> >>
> >> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> >> Sent: Monday, February 13, 2017 5:02 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> >> labs.com>
> >> Cc: lng-odp <lng-odp@lists.linaro.org>
> >> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to
> >> linux helpers
> >>
> >>
> >>
> >> On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo)
> >> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
> >>
> >>
> >> From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
> >> Sent: Friday, February 10, 2017 5:02 PM
> >> To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
> >> Cc: lng-odp <mailto: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 06:23, Petri Savolainen
> >> <mailto:mailto: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.
> >>
> >> Use --enable-helper-linux configuration option to enable
> >> support for Linux helpers.
> >>
> >> Signed-off-by: Petri Savolainen
> >> <mailto:mailto:petri.savolai...@linaro.org>
> >>
> >> Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>
> >>
> >> required 3 way apply
> >>
> >>
> >>
> >> This should be merged. It moves linux dependent helper code under linux
> >> folder. If there would be helper code dependent on some other OS, that
> >> would go to their own helper/OS_foo/ folder. All Linux based ODP
> >> implementations can run this helper code - there is no need to have N
> >> different linux helpers for N different Linux based implementations.
> >>
> >>
> >> Also, the build is currently broken in master for --enable-helper-extn.
> >> E.g. OFP cannot be built against it.
> >>
> >> This is not broken IMHO, it is by design, OFP depends on the helpers,
> we
> >> need helpers to either be support for apps that we maintain and don't
> use
> >> (current case) or we enforce  OFP and others to use the abstract API
> that
> >> all our own executable use. Maintaining code we don't use is dangerous,
> >> you should have to choose to do it, but I like the rename, that is fine
> >> and is progress, hence the review.
> >>
> >> I think splitting out all of all the executables  will make this much
> >> cleaner.
> >> All ODP upstream executables will use the abstract API and be portable
> to
> >> any platform and OS. Meanwhile the odp-Linux repo can have a Linux
> >> specific apis such as the legacy one OFP is using and that is just that
> >> implementations choice, as we have said there is no requirement to use
> >> helpers, or linux, and OFP might want to attach itself to that,  but
> the
> >> tests and examples must remain agnostic until we state we are dropping
> >> that goal.
> >>
> >>
> >> Please try:
> >> ./configure --enable-helper-extn
> >> make
> >>
> >> It does not compile, due to:
> >>
> >> platform/linux-generic/thread.c:282:12: error:
> >> \u2018odph_linux_thread_create\u2019 defined but not used [-
> Werror=unused-
> >> function]
> >>  static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,
> >>
> >>
> >> My patch fixes 

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Maxim Uvarov]

On 02/16/17 11:51, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> 
> 
>> -Original Message-
>> From: Savolainen, Petri (Nokia - FI/Espoo)
>> Sent: Monday, February 13, 2017 5:10 PM
>> To: 'Mike Holmes' <mike.hol...@linaro.org>
>> Cc: lng-odp <lng-odp@lists.linaro.org>
>> Subject: RE: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>>
>>
>> From: Mike Holmes [mailto:mike.hol...@linaro.org]
>> Sent: Monday, February 13, 2017 5:02 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> labs.com>
>> Cc: lng-odp <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>>
>>
>> On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo)
>> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
>>
>>
>> From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
>> Sent: Friday, February 10, 2017 5:02 PM
>> To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
>> Cc: lng-odp <mailto: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 06:23, Petri Savolainen
>> <mailto:mailto: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.
>>
>> Use --enable-helper-linux configuration option to enable
>> support for Linux helpers.
>>
>> Signed-off-by: Petri Savolainen
>> <mailto:mailto:petri.savolai...@linaro.org>
>>
>> Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>
>>
>> required 3 way apply
>>
>>
>>
>> This should be merged. It moves linux dependent helper code under linux
>> folder. If there would be helper code dependent on some other OS, that
>> would go to their own helper/OS_foo/ folder. All Linux based ODP
>> implementations can run this helper code - there is no need to have N
>> different linux helpers for N different Linux based implementations.
>>
>>
>> Also, the build is currently broken in master for --enable-helper-extn.
>> E.g. OFP cannot be built against it.
>>
>> This is not broken IMHO, it is by design, OFP depends on the helpers, we
>> need helpers to either be support for apps that we maintain and don't use
>> (current case) or we enforce  OFP and others to use the abstract API that
>> all our own executable use. Maintaining code we don't use is dangerous,
>> you should have to choose to do it, but I like the rename, that is fine
>> and is progress, hence the review.
>>
>> I think splitting out all of all the executables  will make this much
>> cleaner.
>> All ODP upstream executables will use the abstract API and be portable to
>> any platform and OS. Meanwhile the odp-Linux repo can have a Linux
>> specific apis such as the legacy one OFP is using and that is just that
>> implementations choice, as we have said there is no requirement to use
>> helpers, or linux, and OFP might want to attach itself to that,  but the
>> tests and examples must remain agnostic until we state we are dropping
>> that goal.
>>
>>
>> Please try:
>> ./configure --enable-helper-extn
>> make
>>
>> It does not compile, due to:
>>
>> platform/linux-generic/thread.c:282:12: error:
>> \u2018odph_linux_thread_create\u2019 defined but not used [-Werror=unused-
>> function]
>>  static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,
>>
>>
>> My patch fixes this also.
>>
>>
>> -Petri
>>
> 
> Could we merge this clean up patch. It does not belong to discussions about:
> * what is platform
> * cloud profile
> * abstract threads
> 
> All those can be discussed and done on other mail threads and patches. This 
> patch just explicitly defines that pthread/process functions depend on Linux. 
> Application is free to use those or not. Similarly to e.g. cuckoo hash 
> helper, an application is free to use cuckoo or not. 
> 
> Currently the code in the repo (breaks the build and) hints that 
> pthread/process functions do not depend on Linux, but on an ODP 
> implementation which is wrong. Abstract thread helper may depend on 
> implementation, but these pthread/process functions here are not abstract - 
> they use Linux.
> 
> -Petri
> 

Ok, I applied 1/2. 2/2 has rejects. Can you please rebase it?

Maxim.

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Savolainen, Petri (Nokia - FI/Espoo)
> Sent: Monday, February 13, 2017 5:10 PM
> To: 'Mike Holmes' <mike.hol...@linaro.org>
> Cc: lng-odp <lng-odp@lists.linaro.org>
> Subject: RE: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> 
> 
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Monday, February 13, 2017 5:02 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: lng-odp <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> 
> 
> On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo)
> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
> 
> 
> From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
> Sent: Friday, February 10, 2017 5:02 PM
> To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
> Cc: lng-odp <mailto: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 06:23, Petri Savolainen
> <mailto:mailto: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.
> 
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
> 
> Signed-off-by: Petri Savolainen
> <mailto:mailto:petri.savolai...@linaro.org>
> 
> Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>
> 
> required 3 way apply
> 
> 
> 
> This should be merged. It moves linux dependent helper code under linux
> folder. If there would be helper code dependent on some other OS, that
> would go to their own helper/OS_foo/ folder. All Linux based ODP
> implementations can run this helper code - there is no need to have N
> different linux helpers for N different Linux based implementations.
> 
> 
> Also, the build is currently broken in master for --enable-helper-extn.
> E.g. OFP cannot be built against it.
> 
> This is not broken IMHO, it is by design, OFP depends on the helpers, we
> need helpers to either be support for apps that we maintain and don't use
> (current case) or we enforce  OFP and others to use the abstract API that
> all our own executable use. Maintaining code we don't use is dangerous,
> you should have to choose to do it, but I like the rename, that is fine
> and is progress, hence the review.
> 
> I think splitting out all of all the executables  will make this much
> cleaner.
> All ODP upstream executables will use the abstract API and be portable to
> any platform and OS. Meanwhile the odp-Linux repo can have a Linux
> specific apis such as the legacy one OFP is using and that is just that
> implementations choice, as we have said there is no requirement to use
> helpers, or linux, and OFP might want to attach itself to that,  but the
> tests and examples must remain agnostic until we state we are dropping
> that goal.
> 
> 
> Please try:
> ./configure --enable-helper-extn
> make
> 
> It does not compile, due to:
> 
> platform/linux-generic/thread.c:282:12: error:
> \u2018odph_linux_thread_create\u2019 defined but not used [-Werror=unused-
> function]
>  static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,
> 
> 
> My patch fixes this also.
> 
> 
> -Petri
>

Could we merge this clean up patch. It does not belong to discussions about:
* what is platform
* cloud profile
* abstract threads

All those can be discussed and done on other mail threads and patches. This 
patch just explicitly defines that pthread/process functions depend on Linux. 
Application is free to use those or not. Similarly to e.g. cuckoo hash helper, 
an application is free to use cuckoo or not. 

Currently the code in the repo (breaks the build and) hints that 
pthread/process functions do not depend on Linux, but on an ODP implementation 
which is wrong. Abstract thread helper may depend on implementation, but these 
pthread/process functions here are not abstract - they use Linux.

-Petri

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Wednesday, February 15, 2017 11:40 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: Mike Holmes <mike.hol...@linaro.org>; lng-odp  o...@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 15 February 2017 at 09:34, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> >> Sent: Monday, February 13, 2017 5:41 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> >> labs.com>
> >> Cc: Mike Holmes <mike.hol...@linaro.org>; lng-odp  >> o...@lists.linaro.org>
> >> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to
> >> linux helpers
> >>
> >> This is getting very confusing now: why helper/?  do we have
> >> odp/?: shouldn't  these be symetric?
> >
> >
> > Application (like OFP today) which wants to use e.g. Linux pthread
> helpers include:
> >
> > #include 
> > #include 
> >
> > odph_linux_pthread_create()
> > ...
> > odph_linux_pthread_join()
> >
> >
> > It explicitly uses Linux pthreads through a helper function. There's no
> need to provide these helpers and functions on a non-Linux implementation
> (because there is no Linux).
> >
> > Linux helpers are totally different thing than ODP implementation
> internal directory structure.
> 
> Different: Yes. But related:
> We are back, sadly, to my first question: "what is a platform".
> To that, you, Petri, answered: "platform == implementation". And I agree.

Linux helpers use Linux API and ODP API calls. Those are not aware how an 
implementation is split into files and folders. So, what is platform discussion 
does not belong into this thread. This patch fixes the build issue under and 
renames --enable-helper-thread-extn to --enable-helper-linux, which is more 
logical and explicit about linux helpers.


> 
> Now, can we agree that the above platform definition implies:
> different OS => different platform? Or are you saying that a OSE ODP
> and linux ODP are the same implementation???.

Each vendor decide their folder structure. If they re-use ours you can either 
find e.g.

odp/platform/nxp-ls, which includes code for all supported OSes, or

odp/platform/odp-nxp-ls-linux
odp/platform/odp-nxp-ls-ose
odp/platform/odp-nxp-ls-vxworks

I really don't care as long as everything builds and tests run for each OS. I'd 
prefer platform per vendor + SoC family, so that in the *unlikely case* that 
everything is installed into the same directory you would see

odp/platform/linux-generic
odp/platform/odp-dpdk
odp/platform/odp-nxp-ls
odp/platform/odp-cavium-thunder
...

But, as said every vendor organize their repo as they like.



> 
> If we can agree that, for ODP implementation, different OSes means
> different platforms, do you feel comfortable calling these variation
> differently for the helpers?

Repo/directory structure is own by vendor/implementation/platform. Helpers 
depend on APIs. There's no direct link. Helpers are sorted based on the API(s) 
they depend on.


> 
> What if some helper function requires to be different for a given OS?
> Say for instance, some company wants to implement ODP threads using
> libdill or libmill? (on linux). Or some helper function would depend
> on memory available on a given HW?

odp/helper/linux/pthread.h
odp/helper/linux/dill.h
odp/helper/linux/mill.h
odp/helper/ose/interrupt.h
odp/helper/ose/xyz.h


Helper code uses ODP API exactly the same way as application does: it uses 
capability APIs if it's concerned about some capability. Helper code is part of 
application code.



> 
> Yes, ODP implementation and helpers are 2 differents things, but they
> are facing the same issue: They try to implement a given interface
> (the ODP API  for ODP and the helper API for the helpers) on different
> HW, OS, ... I'd say on different platform. I cannot see why helpers
> variants would only be limited to OSes.

No helpers do not have different implementation for different ODP 
implementation.

Even the "abstract threads" implement (today) abstraction over linux pthread 
and process, but not e.g. OSE threads. You'd need to add some #ifdef __OSE 
there to enable OSE support. Maybe first add odp/helper/ose/thread.c and then 
#ifdef abtract thread to call those functions if application (and helpers) are 
built against OSE (instead of Linux).



> 
> 

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Christophe Milard]

On 15 February 2017 at 09:34, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>
>
>> -Original Message-
>> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
>> Sent: Monday, February 13, 2017 5:41 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> labs.com>
>> Cc: Mike Holmes <mike.hol...@linaro.org>; lng-odp > o...@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>> This is getting very confusing now: why helper/?  do we have
>> odp/?: shouldn't  these be symetric?
>
>
> Application (like OFP today) which wants to use e.g. Linux pthread helpers 
> include:
>
> #include 
> #include 
>
> odph_linux_pthread_create()
> ...
> odph_linux_pthread_join()
>
>
> It explicitly uses Linux pthreads through a helper function. There's no need 
> to provide these helpers and functions on a non-Linux implementation (because 
> there is no Linux).
>
> Linux helpers are totally different thing than ODP implementation internal 
> directory structure.

Different: Yes. But related:
We are back, sadly, to my first question: "what is a platform".
To that, you, Petri, answered: "platform == implementation". And I agree.

Now, can we agree that the above platform definition implies:
different OS => different platform? Or are you saying that a OSE ODP
and linux ODP are the same implementation???.

If we can agree that, for ODP implementation, different OSes means
different platforms, do you feel comfortable calling these variation
differently for the helpers?

What if some helper function requires to be different for a given OS?
Say for instance, some company wants to implement ODP threads using
libdill or libmill? (on linux). Or some helper function would depend
on memory available on a given HW?

Yes, ODP implementation and helpers are 2 differents things, but they
are facing the same issue: They try to implement a given interface
(the ODP API  for ODP and the helper API for the helpers) on different
HW, OS, ... I'd say on different platform. I cannot see why helpers
variants would only be limited to OSes.

If we can agree on the above, we should agree that a common solution
to tackle the same problem would be nice.
On the ODP implementation side, we agreed that a platform was just a
way to diverge for the main delivery.
I still think it makes sense to have the same approach for the helpers:
If we deliver ODP implementation "linux-gen" and "ODP-dpdk" we should
deliver 2 variant of helper for these as well (even if they happen to
be the same).

A constructor willing to have his own ODP (whatever the reason) would
have the framework to diverge: a divergence is a new platform. Both
for helpers and ODP
The interesting question is how do we write the code so that these
divergence would be easy to do and so that maximum code can be reuse.
That is where the next challenge is.  But first we need to agree on
what a platform is and how we handle helpers.

Christophe.

>
>
>>
>> My view is getting clearer and clearer:
>> On the test side, was have made tests for {OS, HW}= {linux/PC} and
>> given the possibility to diverge from these (for any  reason, e.g.
>> difference of HW or OS) with the use of "platform":
>> If a test defined on the common validation test is inappropriate for a
>> ODP developer (whatever the reason), that developer can overwrite this
>> test (or part of it, such as its setup) with an appropriate one on the
>> platform side.
>> Kallray, AFAIK, if using the platform trick for both OS and HW divergence.
>
> If the system under test is not a Linux system. You cannot run linux helper 
> code there and thus you just skip the linux helper tests.
>
>
>>
>> Why not the same approach on the helper side? We give helpers for
>> {linux/PC} and provide a way to redefine these function for those who
>> need to,  on the platform side (e.g. using a weak symbol on the common
>> helpers and letting those who need define the same function as
>> "strong" on the helper platform side?... or any other better trick).
>
> Why a vendor which do not support Linux would rewrite e.g. 
> odph_linux_pthread_create() to emulate Linux pthreads? If the system is not 
> Linux, there is no point to run Linux system calls there and application 
> would not call odph_linux_pthread_create() there.
>
> Remember, helper code is application code. Application would not call Linux 
> system calls in an non-Linux system. So, no need for a non-Linux based ODP 
> implementation to emulate any Linux system calls.
>
>
>>
>> Then, any implementer 

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Monday, February 13, 2017 5:41 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: Mike Holmes <mike.hol...@linaro.org>; lng-odp  o...@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> This is getting very confusing now: why helper/?  do we have
> odp/?: shouldn't  these be symetric?


Application (like OFP today) which wants to use e.g. Linux pthread helpers 
include:

#include 
#include 

odph_linux_pthread_create()
...
odph_linux_pthread_join()


It explicitly uses Linux pthreads through a helper function. There's no need to 
provide these helpers and functions on a non-Linux implementation (because 
there is no Linux).

Linux helpers are totally different thing than ODP implementation internal 
directory structure.


> 
> My view is getting clearer and clearer:
> On the test side, was have made tests for {OS, HW}= {linux/PC} and
> given the possibility to diverge from these (for any  reason, e.g.
> difference of HW or OS) with the use of "platform":
> If a test defined on the common validation test is inappropriate for a
> ODP developer (whatever the reason), that developer can overwrite this
> test (or part of it, such as its setup) with an appropriate one on the
> platform side.
> Kallray, AFAIK, if using the platform trick for both OS and HW divergence.

If the system under test is not a Linux system. You cannot run linux helper 
code there and thus you just skip the linux helper tests.


> 
> Why not the same approach on the helper side? We give helpers for
> {linux/PC} and provide a way to redefine these function for those who
> need to,  on the platform side (e.g. using a weak symbol on the common
> helpers and letting those who need define the same function as
> "strong" on the helper platform side?... or any other better trick).

Why a vendor which do not support Linux would rewrite e.g. 
odph_linux_pthread_create() to emulate Linux pthreads? If the system is not 
Linux, there is no point to run Linux system calls there and application would 
not call odph_linux_pthread_create() there.

Remember, helper code is application code. Application would not call Linux 
system calls in an non-Linux system. So, no need for a non-Linux based ODP 
implementation to emulate any Linux system calls.


> 
> Then, any implementer knows where to place their hacks: on the
> "platform side". Maybe not best, but at least consistent and clear.
> 
> That would just give helpers, with different platform (for any reason)
> implementations.
> 
> The linux-specific helper would of course not fit on the common helper
> part as they are linux specific and cannot be implementation on
> different OS (platform). Once again, I don't understand why we needed
> to do wrappers around well known Linux system calls: IMHO, helpers
> should contains functions that we expect to be delivered on any
> implementation (OS/HW) helpers, so these linux wrappers don't fit
> there.

Linux helpers can be used in Linux based systems - may be 90 - 95% of all data 
plane systems today support or can support Linux.

Non-Linux systems do not need to run Linux applications (helpers).


> If we really want to keep that (I'd vote against), let's create
> another directory name for what it is: "linux-wrappers"... and
> separate them from function we'd expect to see everywhere (the rest of
> the helpers, even if different platform dependent implementations for
> those might exist)

This patch uses odp/helper/linux/xx.h which is pretty explicit about the 
dependency to Linux. Anything under odp/helper/linux is Linux dependent and 
would not build/run on non-Linux systems. Clear?


-Petri





> 
> Christophe
> 
> On 13 February 2017 at 16:09, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
> >
> >
> > From: Mike Holmes [mailto:mike.hol...@linaro.org]
> > Sent: Monday, February 13, 2017 5:02 PM
> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> > Cc: lng-odp <lng-odp@lists.linaro.org>
> > Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to linux helpers
> >
> >
> >
> > On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo)
> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
> >
> >
> > From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
> > Sent: Friday, February 10, 2017 5:02 PM
> > To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
> > Cc: lng-odp <mailto:lng-odp@lists.linaro.

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Christophe Milard]

This is getting very confusing now: why helper/?  do we have
odp/?: shouldn't  these be symetric?

My view is getting clearer and clearer:
On the test side, was have made tests for {OS, HW}= {linux/PC} and
given the possibility to diverge from these (for any  reason, e.g.
difference of HW or OS) with the use of "platform":
If a test defined on the common validation test is inappropriate for a
ODP developer (whatever the reason), that developer can overwrite this
test (or part of it, such as its setup) with an appropriate one on the
platform side.
Kallray, AFAIK, if using the platform trick for both OS and HW divergence.

Why not the same approach on the helper side? We give helpers for
{linux/PC} and provide a way to redefine these function for those who
need to,  on the platform side (e.g. using a weak symbol on the common
helpers and letting those who need define the same function as
"strong" on the helper platform side?... or any other better trick).

Then, any implementer knows where to place their hacks: on the
"platform side". Maybe not best, but at least consistent and clear.

That would just give helpers, with different platform (for any reason)
implementations.

The linux-specific helper would of course not fit on the common helper
part as they are linux specific and cannot be implementation on
different OS (platform). Once again, I don't understand why we needed
to do wrappers around well known Linux system calls: IMHO, helpers
should contains functions that we expect to be delivered on any
implementation (OS/HW) helpers, so these linux wrappers don't fit
there.
If we really want to keep that (I'd vote against), let's create
another directory name for what it is: "linux-wrappers"... and
separate them from function we'd expect to see everywhere (the rest of
the helpers, even if different platform dependent implementations for
those might exist)

Christophe

On 13 February 2017 at 16:09, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>
>
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Monday, February 13, 2017 5:02 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> <petri.savolai...@nokia-bell-labs.com>
> Cc: lng-odp <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to 
> linux helpers
>
>
>
> On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo) 
> <mailto:petri.savolai...@nokia-bell-labs.com> wrote:
>
>
> From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
> Sent: Friday, February 10, 2017 5:02 PM
> To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
> Cc: lng-odp <mailto: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 06:23, Petri Savolainen 
> <mailto:mailto: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.
>
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
>
> Signed-off-by: Petri Savolainen <mailto:mailto:petri.savolai...@linaro.org>
>
> Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>
>
> required 3 way apply
>
>
>
> This should be merged. It moves linux dependent helper code under linux 
> folder. If there would be helper code dependent on some other OS, that would 
> go to their own helper/OS_foo/ folder. All Linux based ODP implementations 
> can run this helper code - there is no need to have N different linux helpers 
> for N different Linux based implementations.
>
>
> Also, the build is currently broken in master for --enable-helper-extn. E.g. 
> OFP cannot be built against it.
>
> This is not broken IMHO, it is by design, OFP depends on the helpers, we need 
> helpers to either be support for apps that we maintain and don't use (current 
> case) or we enforce  OFP and others to use the abstract API that all our own 
> executable use. Maintaining code we don't use is dangerous, you should have 
> to choose to do it, but I like the rename, that is fine and is progress, 
> hence the review.
>
> I think splitting out all of all the executables  will make this much cleaner.
> All ODP upstream executables will use the abstract API and be portable to any 
> platform and OS. Meanwhile the odp-Linux repo can have a Linux specific apis 
> such as the legacy one OFP is using and that is just that implementations 
> choice, as we have said there is no requirement to use helpers, or linux, and 
> OFP might want to attach itself to that,  but the tests and

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

From: Mike Holmes [mailto:mike.hol...@linaro.org] 
Sent: Monday, February 13, 2017 5:02 PM
To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com>
Cc: lng-odp <lng-odp@lists.linaro.org>
Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux 
helpers



On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo) 
<mailto:petri.savolai...@nokia-bell-labs.com> wrote:


From: Mike Holmes [mailto:mailto:mike.hol...@linaro.org]
Sent: Friday, February 10, 2017 5:02 PM
To: Petri Savolainen <mailto:petri.savolai...@linaro.org>
Cc: lng-odp <mailto: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 06:23, Petri Savolainen 
<mailto:mailto: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.

Use --enable-helper-linux configuration option to enable
support for Linux helpers.

Signed-off-by: Petri Savolainen <mailto:mailto:petri.savolai...@linaro.org>

Reviewed-by: Mike Holmes <mailto:mailto:mike.hol...@linaro.org>

required 3 way apply



This should be merged. It moves linux dependent helper code under linux folder. 
If there would be helper code dependent on some other OS, that would go to 
their own helper/OS_foo/ folder. All Linux based ODP implementations can run 
this helper code - there is no need to have N different linux helpers for N 
different Linux based implementations.


Also, the build is currently broken in master for --enable-helper-extn. E.g. 
OFP cannot be built against it.

This is not broken IMHO, it is by design, OFP depends on the helpers, we need 
helpers to either be support for apps that we maintain and don't use (current 
case) or we enforce  OFP and others to use the abstract API that all our own 
executable use. Maintaining code we don't use is dangerous, you should have to 
choose to do it, but I like the rename, that is fine and is progress, hence the 
review.

I think splitting out all of all the executables  will make this much cleaner. 
All ODP upstream executables will use the abstract API and be portable to any 
platform and OS. Meanwhile the odp-Linux repo can have a Linux specific apis 
such as the legacy one OFP is using and that is just that implementations 
choice, as we have said there is no requirement to use helpers, or linux, and 
OFP might want to attach itself to that,  but the tests and examples must 
remain agnostic until we state we are dropping that goal.


Please try:
./configure --enable-helper-extn
make

It does not compile, due to:

platform/linux-generic/thread.c:282:12: error: 
\u2018odph_linux_thread_create\u2019 defined but not used 
[-Werror=unused-function]
 static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,


My patch fixes this also.


-Petri

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Mike Holmes]

On 13 February 2017 at 09:41, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia-bell-labs.com> wrote:

>
>
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Friday, February 10, 2017 5:02 PM
> To: Petri Savolainen <petri.savolai...@linaro.org>
> Cc: lng-odp <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 06:23, Petri Savolainen <mailto:petri.savolainen@
> 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.
>
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
>
> Signed-off-by: Petri Savolainen <mailto:petri.savolai...@linaro.org>
>
> Reviewed-by: Mike Holmes <mailto:mike.hol...@linaro.org>
>
> required 3 way apply
>
>
>
> This should be merged. It moves linux dependent helper code under linux
> folder. If there would be helper code dependent on some other OS, that
> would go to their own helper/OS_foo/ folder. All Linux based ODP
> implementations can run this helper code - there is no need to have N
> different linux helpers for N different Linux based implementations.
>
>
> Also, the build is currently broken in master for --enable-helper-extn.
> E.g. OFP cannot be built against it.
>

This is not broken IMHO, it is by design, OFP depends on the helpers, we
need helpers to either be support for apps that we maintain and don't use
(current case) or we enforce  OFP and others to use the abstract API that
all our own executable use. Maintaining code we don't use is dangerous, you
should have to choose to do it, but I like the rename, that is fine and is
progress, hence the review.

I think splitting out all of all the executables  will make this much
cleaner.
All ODP upstream executables will use the abstract API and be portable to
any platform and OS. Meanwhile the odp-Linux repo can have a Linux specific
apis such as the legacy one OFP is using and that is just that
implementations choice, as we have said there is no requirement to use
helpers, or linux, and OFP might want to attach itself to that,  but the
tests and examples must remain agnostic until we state we are dropping that
goal.


>
> platform/linux-generic/thread.c:282:12: error: 
> \u2018odph_linux_thread_create\u2019
> defined but not used [-Werror=unused-function]
>  static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,
>
>
>
> -Petri
>
>
>
>


-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

From: Mike Holmes [mailto:mike.hol...@linaro.org] 
Sent: Friday, February 10, 2017 5:02 PM
To: Petri Savolainen <petri.savolai...@linaro.org>
Cc: lng-odp <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 06:23, Petri Savolainen 
<mailto: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.

Use --enable-helper-linux configuration option to enable
support for Linux helpers.

Signed-off-by: Petri Savolainen <mailto:petri.savolai...@linaro.org>

Reviewed-by: Mike Holmes <mailto:mike.hol...@linaro.org>

required 3 way apply



This should be merged. It moves linux dependent helper code under linux folder. 
If there would be helper code dependent on some other OS, that would go to 
their own helper/OS_foo/ folder. All Linux based ODP implementations can run 
this helper code - there is no need to have N different linux helpers for N 
different Linux based implementations.


Also, the build is currently broken in master for --enable-helper-extn. E.g. 
OFP cannot be built against it.

platform/linux-generic/thread.c:282:12: error: 
\u2018odph_linux_thread_create\u2019 defined but not used 
[-Werror=unused-function]
 static int odph_linux_thread_create(odph_odpthread_t *thread_tbl,



-Petri

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Mike Holmes]

On 3 February 2017 at 06:23, Petri Savolainen 
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.
>
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
>
> Signed-off-by: Petri Savolainen 
>

Reviewed-by: Mike Holmes 

required 3 way apply


> ---
>  configure.ac   |  17 +-
>  example/Makefile.inc   |   2 +-
>  helper/Makefile.am |  18 +-
>  helper/include/odp/helper/linux/process.h  |  84 ++
>  helper/include/odp/helper/linux/pthread.h  |  66 +
>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>  helper/linux/thread.c  | 239 
>  helper/m4/configure.m4 |   8 +-
>  helper/platform/linux-generic/thread.c | 313
> -
>  helper/test/.gitignore |   1 +
>  helper/test/Makefile.am|   9 +-
>  helper/test/linux-generic/Makefile.am  |   5 -
>  helper/test/linux-generic/process.c|  92 --
>  helper/test/linux-generic/thread.c |  87 --
>  helper/test/linux/Makefile.am  |   5 +
>  helper/test/linux/process.c|  93 ++
>  helper/test/linux/pthread.c|  87 ++
>  test/Makefile.inc  |   2 +-
>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>  test/linux-generic/Makefile.inc|   2 +-
>  20 files changed, 599 insertions(+), 645 deletions(-)
>  create mode 100644 helper/include/odp/helper/linux/process.h
>  create mode 100644 helper/include/odp/helper/linux/pthread.h
>  delete mode 100644 helper/include/odp/helper/platform/linux-generic/
> threads_extn.h
>  create mode 100644 helper/linux/thread.c
>  delete mode 100644 helper/platform/linux-generic/thread.c
>  delete mode 100644 helper/test/linux-generic/Makefile.am
>  delete mode 100644 helper/test/linux-generic/process.c
>  delete mode 100644 helper/test/linux-generic/thread.c
>  create mode 100644 helper/test/linux/Makefile.am
>  create mode 100644 helper/test/linux/process.c
>  create mode 100644 helper/test/linux/pthread.c
>
> diff --git a/configure.ac b/configure.ac
> index daa9b31..b672a1a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -138,18 +138,6 @@ AC_SUBST([with_platform])
>  AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
>
>  
> ##
> -# Determine which helper platform to build for
> -###
> ###
> -AC_ARG_WITH([helper_platform],
> -[AS_HELP_STRING([--with-helper_platform=platform],
> -   [select helper platform to be used, default linux-generic])],
> -[],
> -[with_helper_platform=${with_platform}
> -])
> -
> -AC_SUBST([with_helper_platform])
> -
> -###
> ###
>  # Run platform specific checks and settings
>  
> ##
>  IMPLEMENTATION_NAME=""
> @@ -214,7 +202,7 @@ AM_CONDITIONAL([test_example], [test x$test_example =
> xyes ])
>  AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"])
>  AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
>  AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"])
> -AM_CONDITIONAL([helper_extn], [test x$helper_extn = xyes ])
> +AM_CONDITIONAL([helper_linux], [test x$helper_linux = xyes ])
>
>  
> ##
>  # Setup doxygen documentation
> @@ -345,8 +333,7 @@ AC_MSG_RESULT([
> implementation_name:${IMPLEMENTATION_NAME}
> ARCH_DIR${ARCH_DIR}
> with_platform:  ${with_platform}
> -   with_helper_platform:   ${with_helper_platform}
> -   helper_extn:${helper_extn}
> +   helper_linux:   ${helper_linux}
> prefix: ${prefix}
> sysconfdir: ${sysconfdir}
> libdir: ${libdir}
> diff --git a/example/Makefile.inc b/example/Makefile.inc
> index ea596d5..70e3758 100644
> --- a/example/Makefile.inc
> +++ b/example/Makefile.inc
> @@ -1,6 +1,6 @@
>  include $(top_srcdir)/platform/@with_platform@/Makefile.inc
>  LIB   = $(top_builddir)/lib
> -LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper-@with_helper_platform@
> .la
> +LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper.la
>  AM_CFLAGS += \
> -I$(srcdir) \
> 

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Friday, February 03, 2017 3:37 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> 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 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)

Needed by (synthetic) validation test application that need to run on any 
environment to offer API verification.

> 
> 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.

Most real world applications choose first an operating system and then the 
thread model within that OS. Linux is the largest data plane OS (ecosystem), so 
it's natural for ODP to offer helpers for that. Most real/production grade 
applications would not need OS abstraction layer (option 1) above) from ODP.


> 
> 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/...").

... and
helper/odp-dpdk/
helper/odp-thunderx
helper/nxp
...

... gets ugly. A Linux application using ODP depends only on Linux and ODP 
APIs, not the ODP platform under ODP API.



> 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.

OFP slow path is Linux, not "abstract OS" (as of today at least).

> 
> The Second set of function is not of much value in my eyes: They do
> not provide any kind of ab

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Christophe Milard]

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
>
>
>
>
>

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -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).

-Petri

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Mike Holmes]

On 3 February 2017 at 07:59, Sorin Vultureanu <sorin.vulture...@enea.com> wrote:
> Hi Mike,
>
> My understanding is that you want to remove helper lib, so I have some points 
> why that would be a bad idea:

Not remove helpers, just remove the unused linux spcific API, the
abstract one will remain.

>
> 1. We use these helpers as abstraction layer. The fact that you remove them 
> will add load to change things in OFP. Probably, we will be forced to reuse 
> your deleted code as it provides some abstractization ! That code is still 
> required to run on a platform. We use that abstractization that is right for 
> us and we will be forced to invent other abstractization if you remove yours 
> (if not reuse your code).

But you are not useing the abstraction, you are using the original
linux only API I think.

>
> 2. I strongly believe ODP should provide this process/thread abstractization 
> as the ODP application should be portable! (be it in main ODP lib, or as is 
> now in helper lib)

It does, but you are not calling the abstract API I think

>
> 3. Backward compatibility of code and design (at major or concept level). 
> This means that you can't really remove things and expect ODP developers to 
> be happy with your design changes or the lack of commitment to maintain 
> backward compatibility of any API.

Indeed, and at the same time we have to evolve and move towards a more
cloud friendly configuration, thus the old API was made a compile
option, I am thinking now that a lib to support th old api can remian,
but I dont think it has a place in the general
test/example/perfromance metrics applications, they all use the
abstract helper api.

>
> So in conclusion, my point of view is that you need to make or keep some 
> concept of process/thread that are generic and still have multiple 
> implementations.
>
> I have added Janne and Jere that might have a different point of view, from 
> OFP perspective.
>
> BR,
> Sorin Vultureanu
> Software Engineer
> Linux R
> Email  sorin.vulture...@enea.com
> Phone  +40 723.651.943
>
> www.enea.com
>
>
>
> This message, including attachments, is CONFIDENTIAL. It may also be 
> privileged or otherwise protected by law. If you received this email by 
> mistake please let us know by reply and then delete it from your system; you 
> should not copy it or disclose its contents to anyone. All messages sent to 
> and from Enea may be monitored to ensure compliance with internal policies 
> and to protect our business. Emails are not secure and cannot be guaranteed 
> to be error free as they can be intercepted, a mended, lost or destroyed, or 
> contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of email transmission. Anyone who communicates with us by email accepts these 
> risks.
>
>
>> -Original Message-
>> From: Mike Holmes [mailto:mike.hol...@linaro.org]
>> Sent: Friday, February 03, 2017 2:41 PM
>> To: Christophe Milard <christophe.mil...@linaro.org>
>> Cc: Petri Savolainen <petri.savolai...@linaro.org>; LNG ODP Mailman List
>> <lng-odp@lists.linaro.org>; Sorin Vultureanu <sorin.vulture...@enea.com>
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>> On 3 February 2017 at 07:28, Christophe Milard
>> <christophe.mil...@linaro.org> wrote:
>> > 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".
>> > :-)
>> >
>>
>> CC Sorin, I think OFP may be using them, but I

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Sorin Vultureanu]

Hi Mike,

My understanding is that you want to remove helper lib, so I have some points 
why that would be a bad idea:

1. We use these helpers as abstraction layer. The fact that you remove them 
will add load to change things in OFP. Probably, we will be forced to reuse 
your deleted code as it provides some abstractization ! That code is still 
required to run on a platform. We use that abstractization that is right for us 
and we will be forced to invent other abstractization if you remove yours (if 
not reuse your code).

2. I strongly believe ODP should provide this process/thread abstractization as 
the ODP application should be portable! (be it in main ODP lib, or as is now in 
helper lib)

3. Backward compatibility of code and design (at major or concept level). This 
means that you can't really remove things and expect ODP developers to be happy 
with your design changes or the lack of commitment to maintain backward 
compatibility of any API.

So in conclusion, my point of view is that you need to make or keep some 
concept of process/thread that are generic and still have multiple 
implementations.

I have added Janne and Jere that might have a different point of view, from OFP 
perspective.

BR,
Sorin Vultureanu
Software Engineer
Linux R
Email  sorin.vulture...@enea.com
Phone  +40 723.651.943

www.enea.com



This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


> -Original Message-
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Friday, February 03, 2017 2:41 PM
> To: Christophe Milard <christophe.mil...@linaro.org>
> Cc: Petri Savolainen <petri.savolai...@linaro.org>; LNG ODP Mailman List
> <lng-odp@lists.linaro.org>; Sorin Vultureanu <sorin.vulture...@enea.com>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 3 February 2017 at 07:28, Christophe Milard
> <christophe.mil...@linaro.org> wrote:
> > 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".
> > :-)
> >
> 
> CC Sorin, I think OFP may be using them, but I am not sure that it
> needs to, if OFP wants to be Linux specific its not hard to call
> pthreads etc yourself.
> 
> Have we established that these are not better off as tested examples /
> docs rather than actually in a helpers lib. Given that we do not use
> them in odp-linux at all it feels that they are just clutter.
> 
> Another angle is that maybe this problem is due to having the tests
> for all platforms and OS'es in the same repo as a specific linux
> implimentation, perhaps with the tests all moved out it becomes much
> clearer and odp-linux the implimentation is free to be entirely Linux
> centric becasue the tests will use the agnostic API in a separate repo
> 
> I am glad that we are finally digging though the helpers to get them right
> 
> 
> > Christophe
> >
> >>
> >> Use --enable-helper-linux configuration option to enable
> >> support for Linux helpers.
> >>
> >> Signed-off-by: Petri Savolainen <petri.savolai...@linaro.org

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Mike Holmes]

On 3 February 2017 at 07:28, Christophe Milard
 wrote:
> On 3 February 2017 at 12:23, Petri Savolainen
>  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".
> :-)
>

CC Sorin, I think OFP may be using them, but I am not sure that it
needs to, if OFP wants to be Linux specific its not hard to call
pthreads etc yourself.

Have we established that these are not better off as tested examples /
docs rather than actually in a helpers lib. Given that we do not use
them in odp-linux at all it feels that they are just clutter.

Another angle is that maybe this problem is due to having the tests
for all platforms and OS'es in the same repo as a specific linux
implimentation, perhaps with the tests all moved out it becomes much
clearer and odp-linux the implimentation is free to be entirely Linux
centric becasue the tests will use the agnostic API in a separate repo

I am glad that we are finally digging though the helpers to get them right


> Christophe
>
>>
>> Use --enable-helper-linux configuration option to enable
>> support for Linux helpers.
>>
>> Signed-off-by: Petri Savolainen 
>> ---
>>  configure.ac   |  17 +-
>>  example/Makefile.inc   |   2 +-
>>  helper/Makefile.am |  18 +-
>>  helper/include/odp/helper/linux/process.h  |  84 ++
>>  helper/include/odp/helper/linux/pthread.h  |  66 +
>>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>>  helper/linux/thread.c  | 239 
>>  helper/m4/configure.m4 |   8 +-
>>  helper/platform/linux-generic/thread.c | 313 
>> -
>>  helper/test/.gitignore |   1 +
>>  helper/test/Makefile.am|   9 +-
>>  helper/test/linux-generic/Makefile.am  |   5 -
>>  helper/test/linux-generic/process.c|  92 --
>>  helper/test/linux-generic/thread.c |  87 --
>>  helper/test/linux/Makefile.am  |   5 +
>>  helper/test/linux/process.c|  93 ++
>>  helper/test/linux/pthread.c|  87 ++
>>  test/Makefile.inc  |   2 +-
>>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>>  test/linux-generic/Makefile.inc|   2 +-
>>  20 files changed, 599 insertions(+), 645 deletions(-)
>>  create mode 100644 helper/include/odp/helper/linux/process.h
>>  create mode 100644 helper/include/odp/helper/linux/pthread.h
>>  delete mode 100644 
>> helper/include/odp/helper/platform/linux-generic/threads_extn.h
>>  create mode 100644 helper/linux/thread.c
>>  delete mode 100644 helper/platform/linux-generic/thread.c
>>  delete mode 100644 helper/test/linux-generic/Makefile.am
>>  delete mode 100644 helper/test/linux-generic/process.c
>>  delete mode 100644 helper/test/linux-generic/thread.c
>>  create mode 100644 helper/test/linux/Makefile.am
>>  create mode 100644 helper/test/linux/process.c
>>  create mode 100644 helper/test/linux/pthread.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index daa9b31..b672a1a 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -138,18 +138,6 @@ AC_SUBST([with_platform])
>>  AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
>>
>>  ##
>> -# Determine which helper platform to build for
>> -##
>> -AC_ARG_WITH([helper_platform],
>> -[AS_HELP_STRING([--with-helper_platform=platform],
>> -   [select helper platform to be used, default linux-generic])],
>> -[],
>> -[with_helper_platform=${with_platform}
>> -])
>> -
>> -AC_SUBST([with_helper_platform])
>> -
>> -##
>>  # Run platform specific checks and settings
>>  

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[Christophe Milard]

On 3 February 2017 at 12:23, Petri Savolainen
 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

>
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
>
> Signed-off-by: Petri Savolainen 
> ---
>  configure.ac   |  17 +-
>  example/Makefile.inc   |   2 +-
>  helper/Makefile.am |  18 +-
>  helper/include/odp/helper/linux/process.h  |  84 ++
>  helper/include/odp/helper/linux/pthread.h  |  66 +
>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>  helper/linux/thread.c  | 239 
>  helper/m4/configure.m4 |   8 +-
>  helper/platform/linux-generic/thread.c | 313 
> -
>  helper/test/.gitignore |   1 +
>  helper/test/Makefile.am|   9 +-
>  helper/test/linux-generic/Makefile.am  |   5 -
>  helper/test/linux-generic/process.c|  92 --
>  helper/test/linux-generic/thread.c |  87 --
>  helper/test/linux/Makefile.am  |   5 +
>  helper/test/linux/process.c|  93 ++
>  helper/test/linux/pthread.c|  87 ++
>  test/Makefile.inc  |   2 +-
>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>  test/linux-generic/Makefile.inc|   2 +-
>  20 files changed, 599 insertions(+), 645 deletions(-)
>  create mode 100644 helper/include/odp/helper/linux/process.h
>  create mode 100644 helper/include/odp/helper/linux/pthread.h
>  delete mode 100644 
> helper/include/odp/helper/platform/linux-generic/threads_extn.h
>  create mode 100644 helper/linux/thread.c
>  delete mode 100644 helper/platform/linux-generic/thread.c
>  delete mode 100644 helper/test/linux-generic/Makefile.am
>  delete mode 100644 helper/test/linux-generic/process.c
>  delete mode 100644 helper/test/linux-generic/thread.c
>  create mode 100644 helper/test/linux/Makefile.am
>  create mode 100644 helper/test/linux/process.c
>  create mode 100644 helper/test/linux/pthread.c
>
> diff --git a/configure.ac b/configure.ac
> index daa9b31..b672a1a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -138,18 +138,6 @@ AC_SUBST([with_platform])
>  AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
>
>  ##
> -# Determine which helper platform to build for
> -##
> -AC_ARG_WITH([helper_platform],
> -[AS_HELP_STRING([--with-helper_platform=platform],
> -   [select helper platform to be used, default linux-generic])],
> -[],
> -[with_helper_platform=${with_platform}
> -])
> -
> -AC_SUBST([with_helper_platform])
> -
> -##
>  # Run platform specific checks and settings
>  ##
>  IMPLEMENTATION_NAME=""
> @@ -214,7 +202,7 @@ AM_CONDITIONAL([test_example], [test x$test_example = 
> xyes ])
>  AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"])
>  AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
>  AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"])
> -AM_CONDITIONAL([helper_extn], [test x$helper_extn = xyes ])
> +AM_CONDITIONAL([helper_linux], [test x$helper_linux = xyes ])
>
>  ##
>  # Setup doxygen documentation
> @@ -345,8 +333,7 @@ AC_MSG_RESULT([
> implementation_name:${IMPLEMENTATION_NAME}
> ARCH_DIR${ARCH_DIR}
> with_platform:  ${with_platform}
> -   with_helper_platform:   ${with_helper_platform}
> -   helper_extn:${helper_extn}
> +   helper_linux:   ${helper_linux}
> prefix: