[ECOS] Re: disk access mutex's

[Savin Zlobec]

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 
>is blocked.
>  
>
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.

savin

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss