Hi, [EMAIL PROTECTED] wrote: > "Very portable" almost alwas == "equally crippled on all platforms". > I'm so tired of 'very portable' software.
A general locking facility would have to be system dependent in respect to device identification and naming. All other aspects, especially the generic locking aspects can be done in a portable way. TCP/IP and file system access are portable concepts. > I like the idea of having a convention-- but I would argue against it > locking down devices against all access. A CDROM device is perfectly > capable of answering, eg, ' are you a cdrom?' whil e burning. I > realize that deciding what access is 'safe' is underspecified right > now. A big problem is that it is unclear which ioctls and what SG_IO payload is safe and what possibly disturbs ongoing burns. I had a significant increase in DVD misburns as long as libburn opened and inquired the drive for its bus scan. Libburn's bus scan is an original design feature. Its suppression was a matter of heart to me and lead to my current involvement. Nevertheless the main usage model for libburn with interactive programs would include such a bus scan with each program run. Even multiple scans per run would make sense. So i need to make it safe against other libburn instances and want to make it mutually safe with the other burn programs. > > Note that it doesn't have to be /dev/sg. > > /dev/sg is dead. Long live SG_IO. What about SG_IO via /dev/sg ? :)) > I will not be obeying O_EXCL in cdparanoia, at least in its current > form. However, I also want to make cdparanoia safe in the context of > cdrom devices burning The charms of O_EXCL do not outweight its disadvantages, indeed. (But for now it works for me. That outweights much.) The general solution still seems to be a systemwide central locking service which manages tickets about devices without touching them. The burn programs may decide on their own which of their activities need such a lock ticket or what they deem to be absolutely safe towards interference with others. It is clear that all participants of the locking service need a common naming system (OS specific) and that the service must not be prone to stale locks or race conditions. Open questions: What is the cheapest and most widely available connection mechanism which allows the server to hand out lock tickets and to learn about the demise of a client ? How do our needs intersect with services provided by HAL, resmgr et al ? (For resmgr the answer is rather negative. by now.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
