Re: Request for cooperation with all burn backends
> "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
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
A big problem is that it is unclear which ioctls and
what SG_IO payload is safe and what possibly disturbs
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
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
So i need to make it safe against other libburn instances
and want to make it mutually safe with the other burn
> > 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.
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 :)