[ECOS] Re: disk access mutex's
Thu Sep 2 14:09:00 GMT 2004
Jeff Cooper wrote:
>On Wednesday 01 September 2004 02:01 am, Savin Zlobec wrote:
>>Jeff Cooper wrote:
>>>One thing I'm curious about is the lack of mutex's when accessing the CF
>>>hardware in the Elatec driver.
>>>Is contention for the disk device handled at a layer higher up than the
>>>device driver? I've been digging through the source for the io disk and
>>>haven't found any kind of access control.
>>>Am I just missing where this is being handled? If so, can anyone point
>>>me in the right direction?
>>If you intend to access several partitions simultaneousely or one
>>partition through an fs
>>that doesn't serialize its io operations, then the disk io funs should
>>be mutex protected.
>>In any case you are right io_disk need an mutex and it should be in
>>disk.c not in lower layers.
>Thanks for the info!
>What would be the advantage to handling mutex's in a higher layer rather than
>a lower one?
Since some data is shared between the master disk device and per
partition devices it should be
mutex protected in order for the disk_io layer to be thread safe.
>The only one I can thing of would be that the device driver writer wouldn't
>have to be concerned about knowing where to place the protection and could
>assume that read/write calls are atomic.
>But couldn't that also be considered a disadvantage as well?
>My thought is that someone writing a device driver for a particular piece of
>hardware should know when the hardware needs mutex protection. Doing it in
>the lower layers would allow a finer grain of control over when the hardware
The low level read and write funs are just about fetching or storing one
sector to/from the
hardware device. Most of the hw will be busy during this time and
locking the whole read/write
call should be fine. Maybe some hw with internal buffers could take
advantage of finer
grained locking, but I think that would be hard to implement efficiently
(it would probably
require some awareness of the higher layers like block cache or fs).
I think that locking should go into io_disk and if we ever need more
control over this, then
the io_disk - hw_driver interaction could be extended in order for the
hw driver to signal the
io_disk layer that it wants to take over the locking.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss