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

Re: Request for cooperation with all burn backends


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

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

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.

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 :)


Reply to: