Re: Request for cooperation with all burn backends

[Bill Davidsen <davidsen@tmr.com>]

scdbackup@gmx.net wrote:

> Hi,
>
> Joerg Schilling:
>  
>
> > > Cooperative locking is needed in a way that allows and is based not on
> > > device nodes but on real hardware targets.
> > >      
> Bill Davidsen:
>  
>
> > I'm less sure about cooperative locking, any method which fails if any one 
> > program behaves badly is not scalable.
> >    
>
> It seems to be a hard constraint in the burn community
> that the locking mechanism has to allow free access to
> the drive if the burn program deems its actions harmless.
>
> Full responsibility has as precondition a sufficient
> knowledge of the situation, nevertheless. So the burn
> programs need at least some means to announce their 
> disturbance-sensitive activities on a drive and to detect
> such announcements before starting any activity which
> assumes exclusive usage of the drive.
>
>
> Bill:
>  
>
> > A perfect solution also must address locking of
> > partitions vs. locking the entire device.
> >    
>
> Partitions with burner programs ? 
> How do partitions apply to us ?
>  
Unless you believe that we can get device locking in for just one device 
and ignore the rest, a proposal would have to address locking the device 
for all devices, disk, tape, burner, flash, etc. I doubt that a partial 
solution would find much support, while a solution over all device might.

> > SysV message queue
> >    
>
> msgget, msgsnd, ...
> Indeed a candidate. Installed on my Linux.
>
> Then there is mq_open, mq_send, ...
> Labeled "POSIX". Not installed on my Linux.
>
> I will consider to use this.
> It has not the advantage of TCP/IP to detect the demise
> of a lock holder by the end of the connection.
>
>
> Have a nice day :)
>
> Thomas
>
>
>  


--
bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979