Re: How to coordinate a DVD burn program with udev ?
Hi,
Ben Hutchings:
> I imagine that libburn's commands to the drive cause it to signal a
> status change to the kernel driver, which passes that on to udev.
That's obviously what happens.
udev then loses patience with the drive that is kept internally busy
by a pending SCSI command from libburn, so that the kernel waits with
opening it for udev.
> > But i need instructions. Where to ask for them ?
> Have you asked the udev developers *why* it is doing this problematic
> and apparently redundant work in case of a 'change' event on a CD drive?
Where do i find udev developers ?
I first asked at wodim's mailing list in the hope to meet somebody
who knows about udev.
>From there i was sent to linux-hotplug@vger.kernel.org where a single
person bothered to reply. The problem is there perceived as caused by
the rules which /lib/udev/write_cd_rules wrote into
/etc/udev/rules.d/70-persistent-cd.rules.
So i was sent to Debian, the distro which ships write_cd_rules.
The maintainer of Debian package libburn gave me the advise to ask at
debian-devel, because i perveive it more as a problem of coordination
rather than as bug in udev rules.
Actually i do not so much wonder why udev gropes drives. That's its job.
But somehow its design must have taken into account that udev is not
the only process that uses CD burners.
(The coordination between good-willing Linux burn programs is open(O_EXCL),
which has a non-POSIX meaning on Linux device files. Regrettably
it is already used by filesystem mounters and inspectors as flag
which causes read-only access, whereas we burners use it to discourage
any access.
This difference prevented the definition of a common advisory locking
protocol for all good-willing Linux programs which access CD drives.)
> --
> Ben Hutchings
> If more than one person is responsible for a bug, no one is at fault.
True, true.
Normally i would try to work around the problem. But how to work around
a race condition which has different time characteristics from Linux
installation to Linux installation ?
Currently i can only imagine to wait dozens of seconds after any activity
which could possibly trigger udev.
I.e. to become so slow that no race can happen.
Have a nice day :)
Thomas
Reply to: