Re: Request for cooperation with all burn backends
Thomas,
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: