Re: Request for cooperation with all burn backends
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.
int grab_sg (int blkfd)
Seems to work well for me and my two drives sr0 and sr1.
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
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
(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
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 <firstname.lastname@example.org>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979