Hi,
i managed to work around the problem - at least on my system.
There are at least two oddities involved
- If the kernel events happen, then always on open().
But it is quite unpredictable whether they happen at all.
xorriso and program eject have a higher probability to trigger
kernel
Hi,
Ben Hutchings:
I imagine that libburn's commands to the drive cause it to signal a
status change to the kernel driver, which passes that on to udev.
That's obviously what happens.
udev then loses patience with the drive that is kept internally busy
by a pending SCSI command from libburn,
On Fri, 2011-09-16 at 09:46 +0200, Thomas Schmitt wrote:
[...]
And I don't see any reason why udev should try to
reidentify a CD drive on a 'change' event. I mean, it's not exactly
likely to change itself to be capable of handling a new disc format that
would deserve an additional
Hi,
me:
What is the recommended way for a library resp. a console program
to tell udev, that a CD drive and the media will undergo arbitrary
changes and should not be accessed during that time ?
Ben Hutchings:
There isn't one.
Isn't this a kind of shortcomming ?
I remember that Eduard
Hi,
i am upstream developer of libburn and CD/DVD/BD burn program xorriso.
It seems urgent that i coordinate the activities of libburn with the
activities of udev.
What is the recommended way for a library resp. a console program
to tell udev, that a CD drive and the media will undergo arbitrary
On Thu, 2011-09-15 at 13:29 +0200, Thomas Schmitt wrote:
Hi,
i am upstream developer of libburn and CD/DVD/BD burn program xorriso.
It seems urgent that i coordinate the activities of libburn with the
activities of udev.
What is the recommended way for a library resp. a console program
to
6 matches
Mail list logo
