SUMMARY When burning an Audio CD, K3b seems to pass `dev=/dev/sr0` to cdrecord, which causes the following warning to be printed: ``` Warning: Open by 'devname' is unintentional and not supported. ``` Original author Joerg Schilling intended us to use the SCSI address instead, as provided by `cdrecord -scanbus`, e.g. `dev=2,0,0`. STEPS TO REPRODUCE 1. Burn an Audio CD using K3b 2. Inspect the write log OBSERVED RESULT cdrecord is used wrongly and prints a warning. EXPECTED RESULT cdrecord should be given the SCSI address rather than the device name. ADDITIONAL INFORMATION Confer "Cdrtools device naming" on Schilling's homepage [1]. See also the cdrtools manpage, which points out how the `dev=` option is meant to be used. ``` Cdrtools are based on libscg (the world's first SCSI Pass Through Interface library, created in 1986). Libscg allows to send arbitrary SCSI commands to arbitrary devices and libscg supports 28 different OS platforms. The vast majority of these platforms have no way to access SCSI devices via /dev/* based device nodes. The 5 platforms: AIX, Solaris, Linux, NetBSD, SCO OpenServer are the exceptions that support /dev/* but together they only have aprox. 1% coverage on the installed computer base of the world. Common platforms like Microsoft Windows and OS X (the latter is a POSIX certified platform) that give a 99% coverage of the installed computer base do not implement /dev/* based SCSI access at all. This is why libscg implements the portable interface via the SCSI Common Access Method (CAM) standard addresses instead of using /dev/* entries. Even on Linux, using /dev/* based access to devices is extremely risky as Linux implements more than a single driver per device. Because Linux does not provide a unified DMA implementation for kernel drivers, some of the SCSI drivers that are available for a specific hardware device do not implement DMA at all, while others implement DMA with a too small blocksize. Because DVD writers require working DMA, users that offer /dev/* based SCSI address information may force libscg to use a Linux driver that does not implement DMA and thus cause the write operation to fail. Omitting the cdrtools dev= parameter at all or offering standard CAM addresses allows libscg to auto-select a working Linux driver for the named hardware. ``` [1]: https://cdrtools.sourceforge.net/private/cdrecord.html SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.5.12-100.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-3570K CPU @ 3.40GHz Memory: 7.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 Manufacturer: Gigabyte Technology Co., Ltd.
Another source: https://sourceforge.net/p/cdrtools/mailman/cdrtools-support/ ``` Re: [Cdrtools-support] [Cdrtools-developers] Fwd: An issue about cdrtools From: (Joerg S. <sc...@sc...> - 2021-03-20 14:28:41 Using /dev/* arguments for the dev= option from cdrecord is explicitly called unsupported in the man page and typically causes cdrecord to fail on Linux as a result of the bugs in the Linux kernel or simply as from the fact that Linux implements more than one driver interface for a single device and /dev/* typicalls enforces cdrecord to use the driver variant that does not work correctly. ```