On 28/05/2014 4:52 pm, Sebastian Huber wrote:
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?
Ah yes. Looking forward to it.
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 was actually thinking without POSIX you do not get a buffer cache but
this also works for me.
Does this mean SMP forces POSIX on ? I think it would be a good idea.
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.
I understand that. If the code depends on POSIX to build then SMP or no
SMP does not matter. This means we can visit the use of Classic API
condition variables or POSIX when we need to. The important thing is not
adding an extra conditional build into the mix for this code. There are
already too many build options in RTEMS.
Maybe we can have a performance test of POSIX vs Classic condition
variables to see which is faster using the 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?
Sorry, I mean the bdbuf code.
Chris
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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
