Re: cdrecord problems

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

me:
> > Eduard Bloch was told that there is no problem if
> > only we userland applications coordinate neatly.
Joerg Schilling:
> Alan Cox [...] with his answers to Mr. Bloch, he was correct,
> but I did not see him writing this claim.

That's what i understand from this statement by Alan Cox 
  http://lkml.org/lkml/2007/3/31/175

I interpret this like:
"Kids, manage this yourself, like the Terminalovski
 brothers from the neighbor house did."

Well, Dialup Terminalovski is an ageing web criminal now.
Uucp Terminalovksi lost his job to the Internet.
Kermit Terminalovski went back to showbiz.

Do they really want us to end up like that ?!


Joerg Schilling:
> If he did really write that it is a Linux userland only problem,
> he is of course wrong.

This becomes evident by my failure to coordinate
cdrskin and libblkid. Ted T'so is my witness that i
did consider any known locking mechanism and that
each of them failed to match our needs.
Those needs are not exotic.
We have:
- Contemporary Linux 2.6.
- A library which wants to learn wether any interesting
  data are available. It is willing to stay away from
  anything that is marked as occupied but it runs with
  superuser authority and on very sparse systems.
  It wants to make peek reads from mounted filesystems.
- A burn program which wants to be undisturbed while
  it makes its efforts to populate the world with CD
  or DVD.
Constraints:
- Intolerable would be stale locks. I.e. if the lock
  holder crashes then the lock has to be released
  automatically within a reasonable time. The lock
  must not survive reboots.
- The lock must be bullet proof. I.e. no sneak-in via
  an alternative device file path or device driver.
- It is allowed to be advisory. I.e. applications would
  have to be extended to participate in the effort.
- An older meaning of O_EXCL with block devices mounted
  as filesystems has to be respected. The locking aspect
  of O_EXCL which came from sg to sr is exclusive, while
  the older one allows read access. (sigh)

I'm open to proposals. (Expect some counter arguments
from my side but be assured that i hope to lose in
my role as advocatus diavoli.)


Joerg Schilling:
> People who believe that they may solve the hald problem by
> using O_EXCL did not understand the problem.

I strace'd the activities of hald on a SuSE 9.3
which serves as my 2.6 test system.
I found out that hald does some open(O_EXCL) but soon
closes that fd and opens new fds without O_EXCL.
With those it performs read(), poll() and
ioctl(,CDROM_DRIVE_STATUS,) which obviously cause
trouble.

Please give me some hints if you know more about the
course of those collisions. 


> The only reliable way would be to make hald on Linux
> behave cooperatively.

I am not so sure wether this is possible at all.
We surely lack of means of mutual detection.
I can hardly cooperate if i don't know that there
is somebody else.


Have a nice day :)

Thomas