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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
