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

Re: cdrecord problems


Vladimir Nadvornik:
> > > I think that updating wodim is a good idea anyway,
> > Agreed.
Joerg Schilling:
> NO

Independend of the question wether to use cdrecord,
wodim or cdrskin, it makes sense to upgrade from
earlier wodims to 1.1.6.

It eases the hald problem if one uses the block device
on Linux kernel 2.6. wodim-1.1.6 does this by default.
If only all hal demons would use O_RDWR|O_EXCL with all
their open(2) calls then the world would be nearly ok.

We would still have a race condition about who
may use the drive at all - but the failures would
be less costly and much more understandable to the

Joerg Schilling:
> Hal on Linux is a nightmare.
Rob Bogus:
> If there are problems in hal (and I totally agree there are), they are 
> in hal, and it's not a kernel problem if someone writes an ill-behaved 
> application and then runs it as root.

There are also other usage scenarios where open O_EXCL
is not a viable alternative. What we need is a system
enforced mandatory locking mechanism by which we can
keep any other process from sending commands to our
burner drive via any of the various system drivers.

The bug refered to by Vladimir Nadvornik caused
Eduard Bloch to write to LKML. The reply caused me to
explore the existing possibilities with the friendly
help of Ted T'so and his use cases of libblkid.

The result was clear: On Linux there is currently no
reliable means to protect a drive from interference by
a process which has read-access to the drive.
Any precaution can get circumvented by accident, with
no bad intention, and unavoidable within the respective
use case.

It is a bit depressing.
Shall i appeal to LKML ?
This seems equivalent to the question wether i am
ready to dive into Linux kernel development.

Eduard Bloch was told that there is no problem if
only we userland applications coordinate neatly.
But Ted and me found no way to coordinate cdrskin with
libblkid ... and we really tried.
We detect each other in the moment when the coaster
occurs. Not earlier.

If i just re-iterate Eduard Bloch's request, then i
will very probably receive the same reply. So i can
as well skip that step and start my own kernel
(cough cough).

Are there LKML regulars around here who could give me
some advise ? (Not about forking Linux but about
convincing the kernel developers.)

Have a nice day :)


Reply to: