| |||||||||||||
|
| |||||||||||||
Introducing DVD-R ToolsIntroducing DVD-R ToolsPosted Mar 2, 2006 3:38 UTC (Thu) by stock (guest, #5849)Parent article: Introducing DVD-R Tools "For a bit of history on issues surrounding the cdrecord code, see, for example, some comments about that code's author (Jörg Schilling) by Danny O'Brien in his To Evil! column, and a comment from Linus Torvalds regarding cdrecord and SCSI device numbering issues." cdrecord uses the SCSI device numbering scheme only as a method to systematicly retrieve the correct device. About how that works and the philosophy behind it, i wrote the following at http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html and also in the following email : Date: Sun, 29 Jan 2006 22:31:12 +0100 (CET)
From: Robert M. Stockmann
To: Albert Cahalan
Subject: Re: time to fork/rewrite cdrtools?
On Sun, 29 Jan 2006, Albert Cahalan wrote:
> Date: Sun, 29 Jan 2006 13:08:07 -0500
> From: Albert Cahalan
> To: Robert M. Stockmann
> Subject: Re: time to fork/rewrite cdrtools?
>
> On 1/29/06, Robert M. Stockmann wrote:
> > On Sun, 29 Jan 2006, Albert Cahalan wrote:
>
> > Well forking() takes more as just picking up a cdrtools version and
> > rewriting it. One needs to have access to technical specs of the
> > several 'color' books, have access to propriarity information about
> > vendor pre-written tracks of the several DVD/CD media out there. And
> > one must have tech specs of the details of DVD burner manufactures
> > firmware versions, related to implementation of standards, like
> > DVD-ROM, DVD-R , DVD+R etc. All this seems to be inside the hands ofa
> > single man called Jörg Schilling, who amongst others is a Fraunhofer
> > employee, and has contact to the large industry like Mercedes benz
> > etc.
>
> Some of that can be picked from the cdrecord source, even if only
> after the bug reports come in. I'm wondering how much of this is
> really needed though.
>
> It seems that most of the write modes are useless cruft.
> Do you think anybody actually uses that stuff?
>
> Multi-session is probably cruft too. Games no longer ship with
> a mix of data and audio tracks. Screwy old multimedia presentations
> went out of style with Windows 3.1 and MacOS 7.
>
> > I have a feeling that Schilling, being on the payroll of Fraunhofer,
> > is well 'guided' in his decisions, regarding recording DATA on DVD
> > and CD media. If one connects the dots, you will soon arrive at
> > company's like Disney, Sony, RIAA, MPAA, Philips, making sure that
> > Schilling's employer leaves few room for his 'cdrtools' project.
>
> I wonder what he does there. Perhaps SuSE could hire him.
>
> > Well thats my ramblings on this. I sure like to fork() this burning
> > baby, but it takes more as just a couple of enthousiastic programmers
> > in the DVD burning case.
>
> What gets me is not the DVD issue, but this:
>
> The whole dev=b,t,l thing is complete nonsense. It's not the
> proper way to address a device for Windows, FreeBSD, MacOS X,
> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. All of these
> systems have device names than users expect to use. (yes, even
> HP-UX and IRIX, which don't use /dev/0,0,0 for the names)
> All of these systems can be made to accept the normal names
> for raw SCSI, at the very worst (FreeBSD) needing translation
> before use.
>
> Joerg has the nerve to lie about this. He even posts to the
> linux-kernel mailing list that "users of cdrecord like to run
> cdrecord -scanbus", which is obviously false. Joerg purposely
> documents the dev=/dev/sr0 syntax as "not supported", despite
> being the correct way to burn a CD with Linux.
>
> Every time a confused user comes to Joerg for help, Joerg
> responds by blaming the Linux kernel. Joerg then suggests
> inferior alternatives like Solaris and FreeBSD. Joerg is
> doing his very best to discourage the use of Linux.
>
> Proper CD burning software would never use a /dev/sg* device.
> Joerg is holding back Linux. The /dev/sg* devices should only
> be assigned to devices that don't have normal drivers. This
> would leave /dev/sg* for stuff like scanners. Eliminating the
> second device file would allow kernel developers more freedom
> to change kernel-internal stuff. It would also reduce user
> accidents, including security-related ones involving inconsistant
> access control and mistaken identity.
>
> Proper device detection uses /sys on Linux. On many UNIX-like
> systems with GNOME or KDE, DBUS messages should be used.
>
> I'm thinking that proper emulation of dev=b,t,l misbehavior
> would be OS-specific hacks. Windows gets 0,0,0 to 0,0,25 from
> the letters of the alphabet. Most UNIX-like systems get either this:
>
> b = 0
> t = major number of the device file
> l = minor number of the device file
>
> or this:
>
> Encode the path to the device file, without the /dev/ prefix,
> using 5 characters packed into each number. The characterset
> could be up to 73 characters that occur in /dev filenames.
>
>
Hello Albert,
Well to resume my experience, with Schilling's philosophy of naming
devices inside cdrecord :
There are the following backend drivers inside cdrecord :
sg : Generic transport independent SCSI
pg : SCSI transport for ATAPI over Parallel Port
ATA : ATA Packet specific SCSI transport
(device = ATAPI:x,y,z , but seldom used )
ATA : ATA Packet specific SCSI transport using sg interface
(device = ATA:x,y,z , used in almost all Linux PC's )
RSCSI : Remote SCSI
In full :
[jackson:stock]:(~)$ cdrecord dev=help
Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2004 Jörg Schilling
NOTE: this is OSS DVD extensions for cdrtools and thus may have bugs
related to DVD issues that are not present in the original cdrtools.
For more information see http://crashrecovery.org/oss-dvd.html. The
original cdrtools author should not be bothered with problems in this
version.
Supported SCSI transports for this platform:
Transport name: sg
Transport descr.: Generic transport independent SCSI
Transp. layer ind.:
Target specifier: bus,target,lun
Target example: 1,2,0
SCSI Bus scanning: supported
Open via UNIX device: not supported
Transport name: pg
Transport descr.: SCSI transport for ATAPI over Parallel Port
Transp. layer ind.:
Target specifier: bus,target,lun
Target example: 1,2,0
SCSI Bus scanning: supported
Open via UNIX device: not supported
Transport name: ATA
Transport descr.: ATA Packet specific SCSI transport
Transp. layer ind.: ATAPI:
Target specifier: bus,target,lun
Target example: ATAPI:1,2,0
SCSI Bus scanning: supported
Open via UNIX device: not supported
Transport name: ATA
Transport descr.: ATA Packet specific SCSI transport using sg
interface
Transp. layer ind.: ATA:
Target specifier: bus,target,lun
Target example: 1,2,0
SCSI Bus scanning: supported
Open via UNIX device: not supported
Transport name: RSCSI
Transport descr.: Remote SCSI
Transp. layer ind.: REMOTE:
Target specifier: rscsi@host:bus,target,lun
Target example: REMOTE:rscsi@host:1,2,0
SCSI Bus scanning: supported
Open via UNIX device: not supported
[jackson:stock]:(~)$
In this way cdrecord can query for drives using the SCSI Bus scanning
protocol. First select your backend driver, ie. dev=ATA, and next run
your scan :
[jackson:stock]:(~)$ cdrecord dev=ATA -scanbus
Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2004 Jörg Schilling
NOTE: this is OSS DVD extensions for cdrtools and thus may have bugs
related to DVD issues that are not present in the original cdrtools.
For more information see http://crashrecovery.org/oss-dvd.html. The
original cdrtools author should not be bothered with problems in this
version.
scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
scsibus0:
0,0,0 0) 'PIONEER ' 'DVD-RW DVR-107D' '1.05' Removable CD-ROM
0,1,0 1) 'PIONEER ' 'DVD-RW DVR-109 ' '1.57' Removable CD-ROM
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0 100) '_NEC ' 'DVD_RW ND-2510A ' '2.18' Removable CD-ROM
1,1,0 101) '_NEC ' 'DVD_RW ND-3540A ' '1.01' Removable CD-ROM
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
Schilling's approach to the device naming is inherited from the SCSI
device naming scheme :
[jackson:stock]:(~)$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3120026AS Rev: 3.18
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3120026AS Rev: 3.18
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
[jackson:stock]:(~)$
In the above -scanbus listing we identity :
'_NEC ' 'DVD_RW ND-3540A ' '1.01' Removable CD-ROM = ATA:1,1,0
which means : from the ATA backend driver, we take controller=1
(secondary ide channel) device-id=1 (slave drive) and lun=0. The lun=0
thing is of course a bogus naming here. But i can live with that. Once
Schilling has translated the communication in a scsi method, he can
blindly attach his libscsi and libscg.
And besides, burners which have a real SCSI backend in hardware, i.e.
using the backend driver dev=sg, still have worked flawless for me
here, without having to worry about Linux kernel versions.
The burning with cdrecord is still, as of today, best implemented using
the dev=sg driver.
In effect, Schilling has made it as its default backend driver. Which
means that dev=0,1,0 would use scsi host scsi0 (i.e. the 1st
scsi_hostadapter which is initiated after booting linux) , device ID=1
and lun=0
I assume, now that Torvalds has decided to change his scsi engine
inside coming new linux kernel editions, the alarm bells have gone off
in various places.
And that is not only a real problem inside Schilling's burning
theather. There are more implementations on the linux platform, which
depend heavily on the scsi driver backend present in the current and
older Linux kernels.
Regards,
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net
(Log in to post comments)
Introducing DVD-R Tools Posted Mar 2, 2006 6:02 UTC (Thu) by jamesh (subscriber, #1159) [Link] No one disputes that cdrecord's (bus,target,lun) triples can be used to uniquely identify a particular device on the system at a particular time.
What they do argue is that it is pointless to use the triples for device identification, since you can achieve the same identification by using the device files.
Secondly, given that we use device files to identify the device with mount, cdparanoia and almost every other tool, using (bus,target,lun) triples for writing CDs is inconsistent.
Introducing DVD-R Tools Posted Mar 2, 2006 14:35 UTC (Thu) by nix (subscriber, #2304) [Link] 'The same' identification? I have one CD-ROM drive and two CD burners of the same make on my machine. cdrecord -scanbus is useless: which burner is which? It can't tell me.
But udev knows: /dev/burners/lower and /dev/burners/upper are quite unambiguous.
Introducing DVD-R Tools Posted Mar 6, 2006 10:46 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] I find it pretty asinine that I have to figure out the mapping between one namespace and the other just to get cdrecord to notice my drive. I don't know how many times I screamed in frustration trying to figure out exactly which incantation and which combination of ide vs. ide-scsi would make my drives visible to cdrecord, even when they were visible to everything else, including cdparanoia.
|
|
||||||||||||