Introducing DVD-R Tools [LWN.net]

The DVD-R Tools project has been formed by Bernhard Rosenkraenzer to fill a void in the Linux DVD authoring landscape:

dvdrtools is a fork of cdrtools, with the primary goals of remaining 100% Free Software (dvdrtools is a fork of the last version of cdrtools without any "you are not allowed to modify this section" comments), and adding support for DVD-R/DVD-RW drives and media.

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. In a classic open-source software move, the solution for dealing with personality issues involving the author of some extremely useful code was to fork the project and move on.

Version 0.3.1 of DVD-R Tools and the associated dvdrecord utility was announced on February 25, the description further clarifies the goals of the project:

It is a fork of cdrtools that (as the name indicates) adds support for writing to DVD-R and DVD-RW disks using purely Free Software, that tries to do things the Linux way ("dvdrecord dev=/dev/cdrom whatever.iso") without suggesting to use 2.4 kernels or even other operating systems, uses a standard make system, is maintained in a public svn repository, and does away with a lot of the libc functionality-clones found in cdrtools.

The NEWS file from the software distribution details the progress that has been made since the project's inception. The code is available for download here.

The DVD-R Tools project aims to clean up the cdrecord code, remove support for obsolete compilers, remove duplication of code and in general, produce a more typical open-source software collection. Instead of the typical "standing on the shoulders of giants" concept, this code fork adds ".. in order to to grab the bottom rung of a new ladder".

(Log in to post comments)

Introducing DVD-R Tools

Posted Mar 2, 2006 3:38 UTC (Thu) by stock (guest, #5849) [Link]

"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

Introducing DVD-R Tools

Posted Mar 2, 2006 6:02 UTC (Thu) by jamesh (guest, #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.