On Sun, Jun 27, 2021 at 09:45:07PM +0300, i.kononenko wrote: > > > On 27.06.2021 17:29, Alan Stern wrote: > > Is any of this really needed? What usage scenarios require > > f_mass_storage to emulate a DVD-ROM that couldn't use f_tcm instead? > > I can't see any impediments to supplement the already existing > implementation of MMC-(2/3) specification of multimedia devices to > represent the DVD/BD features. If the kernel presents the CD-ROM SCSI > commands, why the mass_storage:usb-gadget-function still doesn't include > that for DVD/BD? > > Many modern embedded systems (e.g., BMC, OpenBMC) implements their > required features, e.g., Virtual Media Device, which is based on the > usb:gadget:mass-storage. > The purpose of that features is extensive, and their use the mass-storage > not only as a cdrom-device. > > The required features of such systems might expect image back-end files > that size is significant than 2.1Gb, but such medium is not the CD-ROM > device. USB-gadget consumers can incorrectly interpret such device by > loading the wrong driver. I believe that should be the DVD-medium device, > at least. You should include this information in the patch description, so that people will understand why you wrote the patch. > Additionally, please note the current patch also fixes the incorrect > implementation of retrieving TOC/PMA/ATIP data, which is required for the > CD-ROM. One system might correct works with retrieving first with the > last session together, but for some systems, e.g., OS ESXi, OS Windows, > should retrieving first and last border sessions in separate SCSI-request. What's wrong with the existing implementation? Are you talking about the do_read_toc function? The driver only supports one session in any case. In general, fixes to existing code and additions of new code should go in separate patches. Alan Stern
