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-hotp...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98685239718775@192.168.2.69
