Re: Request for cooperation with all burn backends
Hi,
Andy:
> > > int grab_sg (int blkfd)
me:
> > Seems to work well for me and my two drives sr0 and sr1.
Joerg:
> Forget about this "method". It is known not to work reliably on Linux
> and similar moethods will not work at all on other OS.
This is a kind of emergency patch for a particular
problem with (some ?) Linux kernels 2.4 .
I am very thankful to Andy that he addresses old
kernel 2.4 at all. His proposal will allow me to
detect growisofs runs on a drive and to stay off.
> The problem on Linux is device aliasing that results in many independent
> device nodes.
Yep. O_EXCL fails to provide the needed functionality
under many circumstances.
Above function will allow growisofs and libburn to
meet at the same Linux /dev/sgN and there locking
should work.
(Same works fine between cdrecord and libburn.)
> Cooperative locking is needed in a way that allows and is based
> not on device nodes but on real hardware targets.
I agree to this statement in general.
(Above sg grabbing is not a widely usable solution.)
My ideas are about a central dispatcher service which
arbitrates locking requests. It could encapsulate nearly
all OS dependency if we manage to find an OS independend
communications method and make it understand all
our permissible address formats (permissible on the
particlar OS).
If it can use a reliable OS provided locking mechanism:
Very good. It should do.
If not: it has to provide some own functionality for locking.
On Linux i would implement it via scsi address parameters
resp. major,minor device number pairs. Possibly configurable
to teach it about hardware coincidences of distinct
device drivers.
Andy:
> > > Have you seen resmgrd?
me:
> > I found this overview of 2006-09-29:
> > http://forgeftp.novell.com//resmgr/web/README.html
Joerg:
> Last time, I did look at this software, it was full of conceptional bugs
I agree that it does not qualify as solution to our problem.
It offers locking, but in a way that i can top by my own
experiments or by an old NFS-wide locking tool from early
1990s which marks lock files with an expiration date.
(It is a bit fat, though.)
> > Next i will try to find out wether HAL would be of more
> > help.
>
> HAL is known to be a non-cooperative program that interrupts
> CD/DVD writing.
If its concept allows the type of locking we need,
then one could try to negociate a less disturbing
operation with the HAL developers.
In our general usage scenario, HAL would only be one
implementation of a lock mechanism, if ever.
I still plan to evaluate wether it would roughly provide
the needed gestures. But i do not plan to depend on it.
> Sun is just working on a new vold implementation
> for better GNOME support. Let us wait until this has been finished....
Got an URL for me to learn about its suitability for
locking ?
On Solaris our arbiter could be a frontend to vold
if that provides the needed functionality. That would
bring us in sync with other vold locks.
In this case the aribter's only service would be to
provide the standardized communcations protocol
for the burn programs and a gateway to vold.
me:
> > I had a significant increase in DVD misburns as long as
> > libburn opened and inquired the drive for its bus scan.
Joerg:
> Then you did something wrong.
That's well possible. I will try to find out, eventually.
But given my current lack of drive- and transport-level
knowledge this may last a while. I am still suckling
on the previously existing libburn code in that aspect.
So i better try to stay off drives used by programs
which know better.
Andy:
> > [Once again] given that we're talking about Linux,
Joerg:
> If you are talking about Linux only, we should stop this discussion.
We got two levels of abstractions in this topic:
1) The particular 2.4 problem between growisofs and libburn.
2) The general problem that we are quite blind towards the
activities of concurrent burn processes.
Number 1) is on a good way thanks to Andy.
(I'm just waiting for seeing how he integrates grab_sg()
into growisofs.)
Number 2) is still collecting divergent opinions and
might need some time until a proposal emerges which
fulfills the minimal needs without imposing too much
load on the developers.
> It would rather make sense to implement a
> demonstrator on a OS that has a better design and then tell the Linux kernel
> developers what to do.
I am still in favor of doing our own thing in user
space.
One would eventually use OS facilities of sufficient
quality for that, but also to have a generic
implementation concept which is "very portable".
The clients shall not see much diversity between
OSes. They will need to get a unique process id
and to perform the necessary communications with
the arbiter.
Communication transport candidates are plain files
and TCP/IP for now. The convention about the
file addresses resp. TCP/IP port might become
system dependent.
We should not dismiss the idea just because we
do not have a good solution yet.
During the next weeks i will try to implement an
arbiter server and lean client code for it.
How many new lines of code would be acceptable
in our burn programs ?
Which OSes are in similar need of coordination
as Linux is ? Do we have testers for them ?
Have a nice day :)
Thomas
Reply to: