[PATCH 10/12] cpukit/sapi: Resources for bdbuf SMP workaround

[Sebastian Huber]

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 at 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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.