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 <s...@rtems.org> wrote:
Module: rtems
Branch: master
Commit: 1fc2e960cea37e8d78e142c71faec18262f356d2
Changeset:
http://git.rtems.org/rtems/commit/?id=1fc2e960cea37e8d78e142c71faec18262f356d2
Author: Ralf Kirchner <ralf.kirch...@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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
