From: "Thomas Schmitt" <scdbackup@gmx.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: How to coordinate a DVD burn program with udev ?
Date: Mon, 12 Sep 2011 09:12:47 +0000 [thread overview]
Message-ID: <98624465932619@192.168.2.69> (raw)
In-Reply-To: <98658457621000@192.168.2.69>
Hi,
Tom Gundersen wrote:
> Could you possibly use one of the /dev/disk/by-* links instead? As far
> as I understand, the rule generator is being deprecated.
Aside from the general problem, i can of course advise my users to use
whatever is reliably existent and can be unambigously documented.
The files in /dev/disk/by-id seem not to represent any of the two DVD drives.
In /dev/disk/by-path i see them as
/dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0
/dev/disk/by-path/pci-0000:00:14.1-scsi-0:0:0:0
But i understand that these addresses are prone to change at boot time, too.
And they would uglify any program message that contains a drive address.
Alternatively one can find the desired /dev/sr address by running
xorriso -devices
I could even implement in libburn a functionality similar to udev
which identifies drives by unique persistent properties.
But that would not prevent other problems which can arise from
udev trying to inspect the busy CD drive.
> Sorry to not answer your main question, I'm not sure exactly what is
> happening... Maybe someone else can shed some light on it?
The vanishing links are only one example symptom of the general problem
that udev tries to perform SCSI commands on a CD drive that is already
aquired with open(O_EXCL) and might be brought into a state which does
not tolerate such interference.
Especially with media types CD-R, CD-RW and DVD-R this often results in
misburns.
Obviously there are race conditions deciding over success or failure
of the coexistence of udev and burn program.
xorriso is hit more than the others, because it inspects the media
content additionally to the drive's MMC properties.
Nevertheless i can reproduce the problem with wodim.
It is a general one.
libburn and xorriso are part of a project that tries to improve the
neighborhood relations between Linux and burn programs.
Different to growisofs and wodim it is under maintenance (by me),
and different to the author of cdrecord i am willing to follow
instructions from the Linux developers.
But first i need to get such instructions when Linux changes its behavior.
The random permutation of /dev/sr addresses at boot time is such a change.
I understand the recommended way to cope with this device juggling
is to use the udev links.
Now what shall a user think of udev and/or xorriso if this recommended
solution goes up in smoke on first use ?
Is there a better place than this mailing list where i could ask for advise ?
Especially i wonder what the designers of kernel and udev have planned
for the use case of CD/DVD/BD burning.
Have a nice day :)
Thomas
next prev parent reply other threads:[~2011-09-12 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 10:34 How to coordinate a DVD burn program with udev ? Thomas Schmitt
2011-09-12 7:32 ` Tom Gundersen
2011-09-12 9:12 ` Thomas Schmitt [this message]
2011-09-12 9:45 ` Tom Gundersen
2011-09-12 10:17 ` Thomas Schmitt
2011-09-12 11:33 ` Thomas Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98624465932619@192.168.2.69 \
--to=scdbackup@gmx.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).