[rtems commit] libblock: Add RTEMS_BDBUF_USE_PTHREAD

[Chris Johns]

On 3/06/2014 4:03 pm, Sebastian Huber wrote:
> On 2014-06-03 01:58, Chris Johns wrote:
>> On 3/06/2014 3:37 am, Gedare Bloom wrote:
>>> On Mon, Jun 2, 2014 at 10:48 AM, Sebastian Huber <sebh at rtems.org> wrote:
>>>> Module:    rtems
>>>> Branch:    master
>>>> Commit:    1fc2e960cea37e8d78e142c71faec18262f356d2
>>>> Changeset:
>>>> http://git.rtems.org/rtems/commit/?id=1fc2e960cea37e8d78e142c71faec18262f356d2
>>>>
>>>>
>>>> Author:    Ralf Kirchner <ralf.kirchner at embedded-brains.de>
>>>> Date:      Mon Jun  2 14:46:18 2014 +0200
>>>>
>>>> libblock: Add RTEMS_BDBUF_USE_PTHREAD
>>>>
>>>> Use the PTHREAD mutexes and condition variables if available.  This
>>>> helps on SMP configurations to avoid the home grown condition variables
>>>> via disabled preemption.
>>>>
>>>
>>> If the bdbufs work better with this pthread implementation, should we
>>> just get rid of the old code in favor of the new code using
>>> pthread_mutex and condvar? This would mean requiring users who want
>>> bdbufs to also configure for POSIX, which I'm not sure whether that is
>>> a problem or not...
>>>
>>
>> I also agree. It seems normal to me to have POSIX enabled to use a POSIX
>> compliant file system.
>
> The RTEMS_POSIX_API define is mostly POSIX signals and PTHREAD.  It has
> virtually nothing to do with the file system.
>

You and I know this. I am not sure how new users view the option.

>>
>> I think we need to understand the benefit and trade off the
>> --enable-posix
>> option gives us these days. The fewer options like this we have the
>> better our
>> testing results are. There is a limited number of options we can
>> support before
>> the ability to test becomes impossible. We have too many to test now.
>
> This patch changes nothing with respect to testability.

I know .. just my usual whinge about configure options. The patch is fine.

>  It is just one
> more area with an RTEMS_POSIX_API usage.
>
> The general question is if we need --enable-posix at all.  Here we had
> only very small improvements in the last years.  The RTEMS_POSIX_API
> still pulls in a lot of stuff via exinit.c.  I think we need a modular
> initialization like on FreeBSD or Linux to tackle this problem, see also
>
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1593
>

I think the approach here is suitable.

> The new network stack uses this approach also and is very flexible.  The
> only thing necessary is this in our linker command files:
>
>      .rtemsrwset : ALIGN_WITH_INPUT {
>          KEEP (*(SORT(.rtemsrwset.*)))
>      } > REGION_DATA AT > REGION_DATA_LOAD
>
>      .rtemsroset : ALIGN_WITH_INPUT {
>          KEEP (*(SORT(.rtemsroset.*)))
>      } > REGION_RODATA AT > REGION_RODATA_LOAD
>
> With this we add new requirements for the linker:
>
> 1. We need sections.
>
> 2. We need the ability to sort the sections lexicographically by name.
>

Sigh, yes I remember.

Chris