Re: Request for cooperation with all burn backends
Hi,
xiphmont@xiph.org 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
Reply to: