[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for cooperation with all burn backends


this is a request towards all developers of burn backends.

Is it possible we define a common locking mechanism for drives
which does not depend on hardly documented Linux O_EXCL ?

Something simple and very portable would be needed.

I don't quite understand couple of things.

As for locking, or rather serializing access to [relevant] devices. "Very portable" customarily means support for different operating systems. But the trouble is that the other systems, other than Linux that is, might and already do have own ways to serialize the access. It might be impossible and/or simply inappropriate not to use these mechanisms. Doesn't this kind of doom all "very portable" attempts as simply unachievable?

Secondly. Why do you address back-end developers? Is it really a problem between recording programs? Isn't auto-mounting/-playing facilities interfering with ongoing recording *bigger* problem? So if you want to make the noble attempt and spend some time convincing developers time is better spent talking to that developers. IMHO that is:-)

Advisory locking would be sufficient, i think.

So shall we assume that we're actually talking about Linux and Linux only? At least the rest of *this* message implies Linux alone. Please keep it in mind...

Have you seen resmgrd? Well, it didn't seem to catch up, but anyway... Why didn't it catch up? If you want my opinion, I think that all attempts to achieve the goal *purely* in user-land are doomed. 2.6 O_EXCL on block device appears to be sufficient for intended purpose and I personally would rather prefer it back-ported to 2.4 than some user-land facility.

My motivation currently is about growisofs and /dev/srN :

I had the ito open(2) O_EXCL those /dev/srN and /dev/scdM
which have the same SCSI address as the /dev/sgK used by libburn.

Note that it doesn't have to be /dev/sg. Even though different, both 2.4 and 2.6 provide interfaces for passing SCSI commands from user-land through /dev/cdrom. Well, I have to admit I've never tested CDROM_SEND_PACKET interface for non-data recordings... Did libburn developers do? I definitely would (if I were to develop non-data cd recording program:-). Addressing by block device is really more natural, because you share same view as auto-mounting/-playing and hot-plugging facilities and even initial OS installation procedure, and consequently even user view. Not to mention that that's how it works in most OSes anyway.

To summarize. My vote goes for block device addressing, back-porting of O_EXCL to 2.4 and convincing auto-mounting/-playing developers to stick to it. My vote naturally doesn't make it just happen, but unfortunately I don't have time [or energy] to suggest alternative. Note that there are left-overs from experiment with resmsg in dvd+rw-tools code [look for dev_open], so in case of alternative outcome, I'd prefer to see something similar to that, i.e. link to an .so and if available modify behavior at run time. Cheers. A.

Reply to: