Re: Request for cooperation with all burn backends

[Bill Davidsen <davidsen@tmr.com>]

scdbackup@gmx.net wrote:

> Hi,
>
> Andy:
>  
>
> > > > int grab_sg (int blkfd)
> > > >        
> me:
>  
>
> > > Seems to work well for me and my two drives sr0 and sr1.
> > >      
> Joerg:
>  
>
> > Forget about this "method". It is known not to work reliably on Linux
> > and similar moethods will not work at all on other OS.
> >    
>
> This is a kind of emergency patch for a particular
> problem with (some ?) Linux kernels 2.4 .
>
> I am very thankful to Andy that he addresses old
> kernel 2.4 at all. His proposal will allow me to
> detect growisofs runs on a drive and to stay off.
>
>
>  
>
> > The problem on Linux is device aliasing that results in many independent
> > device nodes.
> >    
>
> Yep. O_EXCL fails to provide the needed functionality
> under many circumstances.
> Above function will allow growisofs and libburn to
> meet at the same Linux /dev/sgN and there locking
> should work.
> (Same works fine between cdrecord and libburn.)
>
>
>  
>
> > Cooperative locking is needed in a way that allows and is based
> > not on device nodes but on real hardware targets.
> >    
>
> I agree to this statement in general.
> (Above sg grabbing is not a widely usable solution.)
>
> My ideas are about a central dispatcher service which
> arbitrates locking requests. It could encapsulate nearly
> all OS dependency if we manage to find an OS independend
> communications method and make it understand all
> our permissible address formats (permissible on the
> particlar OS).
>  
I don't know that any solution which depends on every program 
cooperating will be practical, and in fact automounters seem to ignore 
the rest of the world. But if you did want to do a control program, I 
might suggest looking at the SysV message queue features, which are 
portable and provide serialized N-to-M communication, removal of unread 
messages on terminations, etc.

I'm leaning toward Joerg's thought that locks on inodes referencing 
physical devices should work at the device level to avoid aliasing issues.

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