Hi, > Did you try to understand why there are problems on Linux but not on > Solaris?
I tried to understand why there are problems on Linux. I did only watch one older instance of hald and i did no research in Solaris. But i considered conflicts other than those with hald. > if you believe me where the problems are located and > why a simple change at useer level does not help. I believe you that at the Linux user level there is no solution yet. I also believe that a hald which is acting carefully can ease the problem much. But the decisive point for general cooperation is the existence of a reliable locking mechanism for devices. With one single nexus for each vulnerable burner device. Not per device file path, not per inode, not per major-minor device driver number, but per "Logical Unit" as in SAM-3 resp. "multi-media (MM) device" as in MMC-5. (I hope both mean the same thing.) The problems with hald are a special case of the overall problems with burner/reader devices. Besides hald we got conflicts of interest with libblkid and mutually between our burn programs. Probably there are more such problem scenarios. A common pattern is that concurrent instances are sending SCSI commands to the burner while it is in the vulnerable state of sequential writing. Best for us would be if a shared lock would be aquired automatically and mandatorily with any call of open(). For vulnerable activities an interested process should upgrade it to an exclusive lock first (and downgrade to shared afterwards). The shared lock ends only by close(). Bestest would be if an argument came to me which has chances to convince the kernel emminencies. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
