[ECOS] Re: disk access mutex's

[ECOS] Re: disk access mutex's

[Savin Zlobec]

Jeff Cooper wrote:

>I'm working on a CF driver for a Logic Product Development 7760 card engine.  
>I've been looking at the CF driver for the Elatec v850 development board as a 
>basis for the new driver.
>
>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.

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

[ECOS] Re: disk access mutex's

[Jeff Cooper]

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?

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.

Thoughts?

thanks,
Jeff

-- 
Jeff Cooper
Senior Embedded Software Engineer
jeffc@logicpd.com
612-436-5176

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

[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