On 2014-05-28 01:39, Chris Johns wrote:
On 28/05/2014 12:48 am, Ralf Kirchner wrote:
Enabling and disabling preemption as done for single core in bdbuf will not
work for SMP.
Correct. Do the bdbuf tests currently fail on SMP ?
They do not fail since they run in single processor mode.
Thus as a temporary workaround
If this is a workaround what do you see is the proper fix ?
A proper fix is to add condition variables to the Classi API. I think this is
a current GSoC project?
use POSIX mutexes and POSIX condition variables for SMP instead of the
combination of semaphores and preemption handling used for single core.
I question this being conditional on SMP. Why not make it the same for both
builds of RTEMS ? I have no problem with POSIX condition variables being used
as the current method is a poor hacked version (done by me) and should be
removed. Is doing a suitable "proper fix" ?
So you would depend this only on RTEMS_POSIX_API? This is fine for me.
I would rather see us have a single method used for this code and it be tested
and run as much as possible than see the code fragment in this way.
Yes, this is the long term goal, but we need also a short term solution.
Without SMP support for bdbuf, there is no FAT/RFS file system.
These will be allocated automatically.
On the topic of automatic maybe POSIX defaults to on and if disabled this code
is not built.
What do you mean with "this code" the complete bdbuf or only the lock/condition
variables?
I do not think we need more POSIX enable work arounds.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
