DOSFS: why do the sources use _core_mutex?
Victor V. Vengerov
vvv at oktet.ru
Wed May 15 11:35:38 UTC 2002
Hi, Thomas,
It is quite possible that the attached patch is not applied.
Hmmm. I couldn't remember, have I sent it to Joel/bugtracker? Joel, could
you check is it incorporated in latest kernel? (Sorry I'm in a trip
today...)
You are right, it may be a bad practice to use _CORE_* primitives here.
But we need to associate semaphore with every buffer. Using API semaphores
will make RTEMS configuration more complicated (because you have to add
number of buffers configured in the system to number of configured
semaphores; you have to take workspace size into account in this
relations). Also, it will add some memory/performance overhead. We have
decided, considering this and having in mind that libblock library
implements code which can be thought as part of RTEMS itself, we are able
to use internal semaphore representation.
Joel, what is your judgement? Is it OK to use _CORE_ semaphores in
libblock context?
Thanks,
Victor
On Wed, 15 May 2002, Thomas Doerfler wrote:
> Hi,
>
> currently a collegue is busy implementing a IDE block
> device driver to use with the RTEMS dosfs library.
> Progress is rather good, but during debugging we
> detected some problems around the "_CORE_mutex_xxx"
> calls.
>
> I am pretty confident, that these problems have
> something to do with our debug environment (on a
> MPC860), but nevertheless I am a bit confused: I
> thought that these _CORE_mutex" calls are private to
> the RTEMS kernel. So my question: Is it good practice
> to use CORE_mutex_xxx calls outside the kernel? Or
> would it be better to move to semaphores instead?
>
> wkr,
> Thomas Doerfler.
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler Herbststrasse 8
> D-82178 Puchheim Germany
> email: Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_key.htm
>
-------------- next part --------------
diff -uNr rtems-ss-20020301/c/src/libblock/ChangeLog rtems-ss-20020301-patched/c/src/libblock/ChangeLog
--- rtems-ss-20020301/c/src/libblock/ChangeLog Thu Feb 28 23:39:54 2002
+++ rtems-ss-20020301-patched/c/src/libblock/ChangeLog Wed Mar 13 16:26:32 2002
@@ -1,3 +1,10 @@
+2002-03-13 Victor V. Vengerov <vvv at oktet.ru>
+
+ * src/bdbuf.c (find_or_assign_buffer, rtems_bdbuf_read,
+ rtems_bdbuf_sync, rtems_bdbuf_syncdev, bdbuf_swapout_task):
+ Fix bug: disable interrupts and set level properly before
+ _CORE_mutex_Seize invocation).
+
2002-02-28 Joel Sherrill <joel at OARcorp.com>
* Submitted by Victor V. Vengerov <vvv at oktet.ru> and merged
diff -uNr rtems-ss-20020301/c/src/libblock/src/bdbuf.c rtems-ss-20020301-patched/c/src/libblock/src/bdbuf.c
--- rtems-ss-20020301/c/src/libblock/src/bdbuf.c Thu Feb 28 23:39:54 2002
+++ rtems-ss-20020301-patched/c/src/libblock/src/bdbuf.c Wed Mar 13 15:53:46 2002
@@ -1241,6 +1241,7 @@
bd_buf->use_count++;
while (bd_buf->in_progress != 0)
{
+ rtems_interrupt_disable(level);
_CORE_mutex_Seize(&bd_buf->transfer_sema, 0, TRUE,
WATCHDOG_NO_TIMEOUT, level);
}
@@ -1459,6 +1460,7 @@
}
else
{
+ rtems_interrupt_disable(level);
_CORE_mutex_Seize(&bd_buf->transfer_sema, 0, TRUE,
WATCHDOG_NO_TIMEOUT, level);
bd_buf->actual = TRUE;
@@ -1650,6 +1652,7 @@
if (rc == RTEMS_SUCCESSFUL)
{
+ rtems_interrupt_disable(level);
_CORE_mutex_Seize(&bd_buf->transfer_sema, 0, TRUE,
WATCHDOG_NO_TIMEOUT, level);
}
@@ -1691,6 +1694,7 @@
bd_buf = avl_search_for_sync(&pool->tree, dd);
if (bd_buf != NULL /* && bd_buf->modified */)
{
+ rtems_interrupt_disable(level);
_CORE_mutex_Seize(&bd_buf->transfer_sema, 0, TRUE,
WATCHDOG_NO_TIMEOUT, level);
}
@@ -1763,6 +1767,7 @@
{
if (bd_buf->in_progress)
{
+ rtems_interrupt_disable(level);
_CORE_mutex_Seize(&bd_buf->transfer_sema, 0, TRUE, 0, level);
}
}
More information about the users
mailing list