[PATCH 3/4] libblock: Change error status to fatal error

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Apr 12 07:27:42 UTC 2012


Hi Chris,

thanks for the review.

On 04/12/2012 04:52 AM, Chris Johns wrote:
> On 29/03/12 12:30 AM, sebastian.huber at embedded-brains.de wrote:
>> From: Sebastian Huber<sebastian.huber at embedded-brains.de>
>>
>> Calling the bdbuf API functions in the not configured state is now a
>> fatal error.
>
> Moving to a fatal error is fine. I just wonder if a lock not being obtained is
> a little abstract and a more concrete fatal error should be added. The user is
> left to wonder if they have enough mutex resources or there is a failure to
> correctly create the mutex rather than the simpler problem of not calling the
> init routine. This could be based on the result code and not another test in
> the locking path.

Not calling the init routine is the only why to trigger these fatal errors 
(except from system corruption like stack overflow etc.).

We already have special fatal errors for the different lock/unlock operations:

#define RTEMS_BLKDEV_FATAL_BDBUF_SYNC_LOCK     RTEMS_BLKDEV_FATAL_ERROR(11)
#define RTEMS_BLKDEV_FATAL_BDBUF_SYNC_UNLOCK   RTEMS_BLKDEV_FATAL_ERROR(12)
#define RTEMS_BLKDEV_FATAL_BDBUF_CACHE_LOCK    RTEMS_BLKDEV_FATAL_ERROR(13)
#define RTEMS_BLKDEV_FATAL_BDBUF_CACHE_UNLOCK  RTEMS_BLKDEV_FATAL_ERROR(14)

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
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.



More information about the devel mailing list