[ECOS] Re: disk access mutex's

[Savin Zlobec <savin at elatec dot si>]

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