Hi, Andy: > > > int grab_sg (int blkfd) me: > > Seems to work well for me and my two drives sr0 and sr1. Joerg: > Forget about this "method". It is known not to work reliably on Linux > and similar moethods will not work at all on other OS.
This is a kind of emergency patch for a particular problem with (some ?) Linux kernels 2.4 . I am very thankful to Andy that he addresses old kernel 2.4 at all. His proposal will allow me to detect growisofs runs on a drive and to stay off. > The problem on Linux is device aliasing that results in many independent > device nodes. Yep. O_EXCL fails to provide the needed functionality under many circumstances. Above function will allow growisofs and libburn to meet at the same Linux /dev/sgN and there locking should work. (Same works fine between cdrecord and libburn.) > Cooperative locking is needed in a way that allows and is based > not on device nodes but on real hardware targets. I agree to this statement in general. (Above sg grabbing is not a widely usable solution.) My ideas are about a central dispatcher service which arbitrates locking requests. It could encapsulate nearly all OS dependency if we manage to find an OS independend communications method and make it understand all our permissible address formats (permissible on the particlar OS). If it can use a reliable OS provided locking mechanism: Very good. It should do. If not: it has to provide some own functionality for locking. On Linux i would implement it via scsi address parameters resp. major,minor device number pairs. Possibly configurable to teach it about hardware coincidences of distinct device drivers. Andy: > > > Have you seen resmgrd? me: > > I found this overview of 2006-09-29: > > http://forgeftp.novell.com//resmgr/web/README.html Joerg: > Last time, I did look at this software, it was full of conceptional bugs I agree that it does not qualify as solution to our problem. It offers locking, but in a way that i can top by my own experiments or by an old NFS-wide locking tool from early 1990s which marks lock files with an expiration date. (It is a bit fat, though.) > > Next i will try to find out wether HAL would be of more > > help. > > HAL is known to be a non-cooperative program that interrupts > CD/DVD writing. If its concept allows the type of locking we need, then one could try to negociate a less disturbing operation with the HAL developers. In our general usage scenario, HAL would only be one implementation of a lock mechanism, if ever. I still plan to evaluate wether it would roughly provide the needed gestures. But i do not plan to depend on it. > Sun is just working on a new vold implementation > for better GNOME support. Let us wait until this has been finished.... Got an URL for me to learn about its suitability for locking ? On Solaris our arbiter could be a frontend to vold if that provides the needed functionality. That would bring us in sync with other vold locks. In this case the aribter's only service would be to provide the standardized communcations protocol for the burn programs and a gateway to vold. me: > > I had a significant increase in DVD misburns as long as > > libburn opened and inquired the drive for its bus scan. Joerg: > Then you did something wrong. That's well possible. I will try to find out, eventually. But given my current lack of drive- and transport-level knowledge this may last a while. I am still suckling on the previously existing libburn code in that aspect. So i better try to stay off drives used by programs which know better. Andy: > > [Once again] given that we're talking about Linux, Joerg: > If you are talking about Linux only, we should stop this discussion. We got two levels of abstractions in this topic: 1) The particular 2.4 problem between growisofs and libburn. 2) The general problem that we are quite blind towards the activities of concurrent burn processes. Number 1) is on a good way thanks to Andy. (I'm just waiting for seeing how he integrates grab_sg() into growisofs.) Number 2) is still collecting divergent opinions and might need some time until a proposal emerges which fulfills the minimal needs without imposing too much load on the developers. > It would rather make sense to implement a > demonstrator on a OS that has a better design and then tell the Linux kernel > developers what to do. I am still in favor of doing our own thing in user space. One would eventually use OS facilities of sufficient quality for that, but also to have a generic implementation concept which is "very portable". The clients shall not see much diversity between OSes. They will need to get a unique process id and to perform the necessary communications with the arbiter. Communication transport candidates are plain files and TCP/IP for now. The convention about the file addresses resp. TCP/IP port might become system dependent. We should not dismiss the idea just because we do not have a good solution yet. During the next weeks i will try to implement an arbiter server and lean client code for it. How many new lines of code would be acceptable in our burn programs ? Which OSes are in similar need of coordination as Linux is ? Do we have testers for them ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]