Hi, > Seems quite civil to me. Nothing vituperative. Alan Cox doesn't agree > with him, but that's quite another matter.
It's the outcome of the discussion. Eduard's cause (and mine and Andy Polyakov's and even Joerg Schilling's) got defeated without real consideration. The list regulars who bothered, threw generic statements like "hardsware broken" (note the hasty typing), unrelated criticism of "sg" versus "sr" (problem is on both, need for sg was on kernel 2.4), and true but futile criticism towards HAL, the runtime systemd of that time. Alan Cox weighed in by his authority with half-knowledge of SCSI. Transactions are atomic, that's true. But MMC describes drive states where no drive inspection commands are allowed. And again HAL was blamed, as if we upstream programmers had any influence on such software. Without proving it, he stated that there are plenty of locking mechanisms in userspace. Mentioning "COBOL" _is_ an insult, finally. The people who should have known better did not weigh in. There are friendly and warm hearted ones, as i learned when i tried to negociate a locking protocol which includes Ted T'so's blkid. We discussed it a while, i began to sketch protocols, they became more and more complicated, and finally we had to realize that none would truely work. We rely now on open(O_EXCL) in its non-POSIX Linux meaning for device files as advisory locking. But for mount and blkid it means: Is mounted, use read-only. For burn programs it means: Don't use. The intersection of both meanings suffices for DVD+RW, BD-RE, and even DVD+R, BD-R. But not for CD-R, DVD-R. Lesson learned: Be ready to fight off at least three kernel eminencies, by quoting specs and commit history, in order to make your point. Then, maybe, you have a chance to be taken for serious. Being DD and one of the heroes who freed LKML from cdrtools quarrels was not enough. Imagine what happens if i stumble in by a mail "Concurrend SG_IO on multiple drives worked much better in 2.6" Have a nice day :) Thomas
