[rtems commit] libblock: Add RTEMS_BDBUF_USE_PTHREAD

Chris Johns chrisj at rtems.org
Tue Jun 3 07:25:41 UTC 2014

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.*)))
>      .rtemsroset : ALIGN_WITH_INPUT {
>          KEEP (*(SORT(.rtemsroset.*)))
> 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.


More information about the devel mailing list