From Michael.Karcher@fu-berlin.de Fri Dec 03 02:23:31 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POKMz-0003UV-JO>; Fri, 03 Dec 2010 02:23:29 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POKMz-0002kU-DL>; Fri, 03 Dec 2010 02:23:29 +0100 Received: from i59f7f4b7.versanet.de ([89.247.244.183] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POKMy-0003Rr-W4>; Fri, 03 Dec 2010 02:23:29 +0100 From: Michael Karcher To: linux-minidisc@lists.fu-berlin.de Content-Type: multipart/mixed; boundary="=-3WqsoIeOqIrSdj99IMmh" Date: Fri, 03 Dec 2010 03:23:27 +0100 Message-ID: <1291343007.6070.22.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-Originating-IP: 89.247.244.183 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291339409-00000C0F-79BA7D07/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000187, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: appro@fy.chalmers.se Subject: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 01:23:31 -0000 --=-3WqsoIeOqIrSdj99IMmh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit [Cc: to the dvd+rw-tools maintainer to let him know of the patches] Hello developers, I know we already got libscg up and running on all three operating systems that are our main target. But the original libscg by Joerg Schilling has the disadvantage that it is centered around the Solaris way of addressing SCSI devices by bus/dev/lun, which does not fit the model on windows, and also in uncomfortable to deal with on Linux. On Linux, libscg thankfully supports "open by devname" which avoids the abstraction into bus/dev/lun we don't need if we are just interested in the Hi-MD stuff, while on Windows, "open by devname" is not supported. libusal (the fork by Debain people around Eduard Bloch) adds support for opening by device name, but hacks it into the present infrastructure in a not exactly clean way - and for example still scans all drives to assign bus numbers. I found that dvd+rwtools contains a refreshingly simple GPLed (without any restrictions like "you need to modify author name" and so on) SCSI abstraction layer that covers the following operating systems: Linux, OpenBSD/NetBSD, Solaris (license for distribution maybe questionable), FreeBSD, HP-UX, IRIX, Win32, Mac OS X. (see: http://fy.chalmers.se/~appro/linux/DVD+RW/ search for "run Linux") The nice thing is that this library does not even think about adding some abstraction on device naming, so "/dev/sdb" works out-of-the-box on Linux while "E:" works out-of-the-box on Windows. I don't have a MacOS to test here. Sources for dvd+rw-tools can be obtained from here: http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ Patches (one for a bug in the Linux header, one to suppress lots of warnings to compile with MinGW, one to lift the restriction of only being able to work on CD/DVD drives) are attached to this mail, as well as a simple test program that sends an "INQUIRY" SCSI command (reads vendor/model/revision). I would like to have it tested on MacOS X, too, if someone cares. It looks like a device node name is expected in the MacOS case too, just as in Linux. To use the SCSI layer, you just need transport.hxx, win32err.h and asctable.h from the dvd+rw-tools package. The only small drawback of this code compared to libscg is that this code is in C++, but as it in fact does not really make use of C++ except for making Scsi_Command a class, it integrates quite well even into C projects. I wouldn't have problems to add this small amount of C++ to libhimd. Regards, Michael Karcher --=-3WqsoIeOqIrSdj99IMmh Content-Disposition: attachment; filename="suppress-mingw-warnings.diff" Content-Type: text/x-patch; name="suppress-mingw-warnings.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- ../dvd+rw-tools-7.1/win32err.h.orig 2010-12-03 02:57:54.000000000 +0100 +++ win32err.h 2010-12-03 02:59:05.000000000 +0100 @@ -1,16 +1,5 @@ -# define EINVAL ERROR_BAD_ARGUMENTS -# define ENOMEM ERROR_OUTOFMEMORY # define EMEDIUMTYPE ERROR_MEDIA_INCOMPATIBLE # define ENOMEDIUM ERROR_MEDIA_OFFLINE -# define ENODEV ERROR_BAD_COMMAND -# define EAGAIN ERROR_NOT_READY -# define ENOSPC ERROR_DISK_FULL -# define EIO ERROR_NOT_SUPPORTED -# define ENXIO ERROR_GEN_FAILURE -# define EBUSY ERROR_SHARING_VIOLATION -# define ENOENT ERROR_FILE_NOT_FOUND -# define ENOTDIR ERROR_NO_VOLUME_LABEL -# define EINTR ERROR_OPERATION_ABORTED # define FATAL_START(e) (0x10000|(e)) # define FATAL_MASK 0x0FFFF --=-3WqsoIeOqIrSdj99IMmh Content-Disposition: attachment; filename="win32-not-only-CD.diff" Content-Type: text/x-patch; name="win32-not-only-CD.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- ../dvd+rw-tools-7.1/transport.hxx.orig 2010-12-03 02:43:34.000000000 +0100 +++ transport.hxx 2010-12-03 02:58:57.000000000 +0100 @@ -1297,14 +1297,21 @@ int associate (const char *file,const struct stat *ref=NULL) { char dev[32]; sprintf(dev,"%.*s\\",sizeof(dev)-2,file); - if (GetDriveType(dev)!=DRIVE_CDROM) - return errno=EINVAL,0; sprintf(dev,"\\\\.\\%.*s",sizeof(dev)-5,file); fd=CreateFile (dev,GENERIC_WRITE|GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,OPEN_EXISTING,0,NULL); if (fd!=INVALID_HANDLE_VALUE) - filename=strdup(dev); + { /* test that SCSI Passthrough is supported by sending test unit ready */ + for(int i = 0;i < 8;++i) + this->operator[](0) = 0; + if(transport() == -1) + { CloseHandle(fd); + fd = INVALID_HANDLE_VALUE; + errno = EINVAL; + } else + filename=strdup(dev); + } return fd!=INVALID_HANDLE_VALUE; } unsigned char &operator[] (size_t i) --=-3WqsoIeOqIrSdj99IMmh Content-Disposition: attachment; filename="workaround-linux-headers.diff" Content-Type: text/x-patch; name="workaround-linux-headers.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- ../dvd+rw-tools-7.1/transport.hxx.orig 2010-12-03 02:43:34.000000000 +0100 +++ transport.hxx 2010-12-03 02:58:57.000000000 +0100 @@ -139,6 +139,7 @@ #if defined(__linux) +#include #include #include #include --=-3WqsoIeOqIrSdj99IMmh Content-Disposition: attachment; filename="test.cpp" Content-Type: text/x-c++src; name="test.cpp"; charset="UTF-8" Content-Transfer-Encoding: 7bit #include #include #include #include #include "transport.hxx" int main(int argc, char ** argv) { using std::cerr; using std::cout; using std::endl; Scsi_Command cmd; char response[96]; if(!cmd.associate(argv[1])) { cerr << "Can't associate"; return 1; } cmd[0] = 0x12; cmd[1] = 0; cmd[2] = 0; /* page code */ cmd[3] = 0; cmd[4] = 96; cmd[5] = 0; if(cmd.transport(READ,response,96)) { cerr << "Can't execute"; return 1; } cout << "Vendor: " << std::string(response+8,8) << "; Model: " << std::string(response+16,16) << "; Revision " << std::string(response+32,4) << endl; return 0; } --=-3WqsoIeOqIrSdj99IMmh-- From glaubitz@physik.fu-berlin.de Fri Dec 03 23:04:19 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POdjk-0001ij-W0>; Fri, 03 Dec 2010 23:04:17 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POdjk-0006pK-Se>; Fri, 03 Dec 2010 23:04:16 +0100 Received: from kri3-1x-dhcp348.studby.uio.no ([193.157.241.96]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POdjk-0008BB-KL>; Fri, 03 Dec 2010 23:04:16 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Adrian Glaubitz In-Reply-To: <1291343007.6070.22.camel@aquila> Date: Fri, 3 Dec 2010 23:04:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CC11874-AD13-4790-B8A4-9DEF5F9419DF@physik.fu-berlin.de> References: <1291343007.6070.22.camel@aquila> To: Michael Karcher X-Mailer: Apple Mail (2.1082) X-Originating-IP: 193.157.241.96 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291413856-00000C0F-5FF658AB/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000177, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: appro@fy.chalmers.se, linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 22:04:19 -0000 Hi Michael, On Dec 3, 2010, at 3:23 AM, Michael Karcher wrote: >=20 > I found that dvd+rwtools contains a refreshingly simple GPLed (without > any restrictions like "you need to modify author name" and so on) SCSI > abstraction layer that covers the following operating systems: > Linux, OpenBSD/NetBSD, Solaris (license for distribution maybe > questionable), FreeBSD, HP-UX, IRIX, Win32, Mac OS X. > (see: http://fy.chalmers.se/~appro/linux/DVD+RW/ search for "run = Linux") >=20 > The nice thing is that this library does not even think about adding > some abstraction on device naming, so "/dev/sdb" works out-of-the-box = on > Linux while "E:" works out-of-the-box on Windows. I don't have a MacOS > to test here. This is incredibly good news. I was honestly never happy with having to = deal with libscg for the reasons you mentioned and I always had a bad feeling about the CDDL license of the original package. Now, when we can actually use GPLed software which even seems to be easier to work with, I will be fully supporting this solution and prefer = it over our old version using cdrtools. >=20 > Sources for dvd+rw-tools can be obtained from here: > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ >=20 > Patches (one for a bug in the Linux header, one to suppress lots of > warnings to compile with MinGW, one to lift the restriction of only > being able to work on CD/DVD drives) are attached to this mail, as = well > as a simple test program that sends an "INQUIRY" SCSI command (reads > vendor/model/revision). I would like to have it tested on MacOS X, = too, > if someone cares. It looks like a device node name is expected in the > MacOS case too, just as in Linux. Ok. I think I would like to wait for a reply from the dvd+rw-tools = developers, especially it would be that your patches be merged into upstream before we start doing any work on implementing it that way. It would be very nice to be able to link dynamically to the tools on Linux, to keep the = code as clean and lean as possible. And I prefer not to fork the code our own and merge it into our branch. This way we will always receive any bugfixes and updates in dvd+rw-tools automatically. As for MacOS X, I can give it a try on my Macbook and also on the Mac Mini, I think that it shouldn't be so much of a big deal to compile and run it. Unfortunately, I don't have any MiniDisc hardware lying around in Norway to test, but I think I could use some USB sticks or harddisks or even CDROM. Fortunately, the tools are also easily installable through Macports [1]. Thanks a lot for investigating into that. I would very glad if we can drop libscg in favor of dvd+rw-tools. Adrian [1] = http://trac.macports.org/browser/trunk/dports/sysutils/dvdrw-tools/Portfil= e= From Michael.Karcher@fu-berlin.de Sat Dec 04 00:10:57 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POemF-00046n-Rs>; Sat, 04 Dec 2010 00:10:55 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POemF-0005rU-PD>; Sat, 04 Dec 2010 00:10:55 +0100 Received: from i59f7ce05.versanet.de ([89.247.206.5] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POemF-0002dy-54>; Sat, 04 Dec 2010 00:10:55 +0100 From: Michael Karcher To: Adrian Glaubitz In-Reply-To: <4CC11874-AD13-4790-B8A4-9DEF5F9419DF@physik.fu-berlin.de> References: <1291343007.6070.22.camel@aquila> <4CC11874-AD13-4790-B8A4-9DEF5F9419DF@physik.fu-berlin.de> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Dec 2010 00:10:52 +0100 Message-ID: <1291417852.6295.36.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Originating-IP: 89.247.206.5 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291417855-00000C0F-9E4FA84E/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.433238, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Algerien.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: appro@fy.chalmers.se, linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 23:10:57 -0000 Am Freitag, den 03.12.2010, 23:04 +0100 schrieb Adrian Glaubitz: > we start doing any work on implementing it that way. It would be very > nice to be able to link dynamically to the tools on Linux, to keep the code > as clean and lean as possible. The whole implementation is currently inside a header file, so you can't avoid to to have it linked into your program. > As for MacOS X, I can give it a try on my Macbook and also on the > Mac Mini, I think that it shouldn't be so much of a big deal to > compile and run it. Unfortunately, I don't have any MiniDisc hardware > lying around in Norway to test, but I think I could use some USB > sticks or harddisks or even CDROM. Fortunately, the tools are > also easily installable through Macports [1]. Forget about USB sticks - I wasted enough time on that today. On Mac OS, you just can not send raw SCSI commands to USB sticks, even not with libscg. Mac OS prevents raw SCSI access to devices Mac OS has a driver for except under special circumstances. To send raw SCSI commands, you need to obtain a SCSITaskDeviceInterface for the device in question. If the device has no Mac OS driver at all, like e.g. SCSI tape drives, MacOS makes it possible to get this interface directly, by aquiring a "plugin" of the type SCSITaskDeviceUserClient and asking that for the SCSITaskDeviceInterface. The availability of this plugin is explicitly given by the property "SCSITaskDeviceCategory" that has the value "SCSITaskUserClientDevice". For CD writers, the CD authoring application also needs raw SCSI access, although Mac OS (of course) does have a CDROM driver, so the SCSITaskDeviceUserClient plugin is not available. But Mac OS helpfully adds another plug-in instead - it's the MMCDeviceUserClient plug-in. (MMC = Multimedia Commandset) This plug-in can be queried for a MMCDeviceInterface interface which then in turn can deliver a SCSITaskDeviceInterface. The availability of the MMCDeviceUserClient plugin is explicitly stated by the property "SCSITaskDeviceCategory" having the value "SCSITaskAuthoringDevice". Now, as we are lucky, Sony installs a driver for their Hi-MD recorders in Mac OS. The Sony driver re-adds the capability of sending raw SCSI commands to the USB mass storage disk device. It works like in the no-driver case by querying for a SCSITaskDeviceUserClient plug-in on the correct device object. The device class here is the "com_sony_driver_SonyMagicGateNub", which has th "SCSITaskDeviceCategory" property set to "SonyMagicGateUserClientDevice". This Sony-special string is not really what a general-purpose SCSI Library needs, but there is an easy workaround that doesn't need any sony specific stuff to support this kind of devices. Now the neat trick how to detect the Sony way of sending SCSI commands without special-casing it: There is a property called "IOCFPlugInTypes", which is a dictionary, whose keys are the GUIDs of the supported plugins. The Sony driver as well as the generic MacOS driver for non-supported SCSI device classes both list the SCSITaskDeviceUserClient UUID here: kIOSCSITaskDeviceUserClientTypeID = {7D66678E-08A2-11D5-A1B8-0030657D052A} while CD/DVD/BluRay drives list the MMCDeviceUserClient UUID here: kIOMMCDeviceUserClientTypeID = {97ABCF2C-23CC-11D5-A0E8-003065704866} So instead of what dvd+rw-tools does now (searching for SCSITaskDeviceInterface = SCSITaskAuthoringDevice), I suggest to instead search for the UUIDs in the IOCFPlugInTypes dictionary - and support both the indirect interface acquisition through the MMCDeviceInterface as well as the direct aquisition of a SCSITaskDeviceInterface (which will work on non-supported SCSI device classes and the Sony devices). > Thanks a lot for investigating into that. I would very glad if we can > drop libscg in favor of dvd+rw-tools. I did not yet implement the suggested change, but I am quite confident that it will work. I include ioreg dumps for a Hi-MD device and the internal DVD writer of a Mac Mini. Regards, Michael Karcher +-o Hi-MD@fd100000 | { | "idVendor" = 1356 | "IOUserClientClass" = "IOUSBDeviceUserClientV2" | "Device Speed" = 2 | "iSerialNumber" = 3 | "Requested Power" = 250 | "Bus Power Available" = 250 | "kHasMSCInterface" = Yes | "IOGeneralInterest" = "IOCommand is not serializable" | "bDeviceClass" = 0 | "USB Product Name" = "Hi-MD" | "bNumConfigurations" = 1 | "USB Serial Number" = "????????????" | "iManufacturer" = 1 | "USB Vendor Name" = "Sony" | "bcdDevice" = 256 | "bDeviceSubClass" = 0 | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | "sessionID" = 1242052451452390 | "iProduct" = 2 | "bMaxPacketSize0" = 64 | "locationID" = 18446744073660268544 | "Low Power Displayed" = No | "uid" = "USB:054C0287????????????" | "idProduct" = 647 | "USB Address" = 6 | "bDeviceProtocol" = 0 | "PortNum" = 1 | } | +-o IOUSBCompositeDriver | { | "IOProviderClass" = "IOUSBDevice" | "bDeviceClass" = 0 | "IOMatchCategory" = "IODefaultMatchCategory" | "IOProbeScore" = 50000 | "bDeviceSubClass" = 0 | "CFBundleIdentifier" = "com.apple.driver.AppleUSBComposite" | "IOClass" = "IOUSBCompositeDriver" | } | +-o IOUSBInterface@0 | { | "IOUserClientClass" = "IOUSBInterfaceUserClientV2" | "idProduct" = 647 | "IOCFPlugInTypes" = {"2d9786c6-9ef3-11d4-ad51-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | "iInterface" = 0 | "bAlternateSetting" = 0 | "bConfigurationValue" = 1 | "bInterfaceProtocol" = 80 | "bInterfaceNumber" = 0 | "bInterfaceSubClass" = 5 | "idVendor" = 1356 | "bInterfaceClass" = 8 | "locationID" = 18446744073660268544 | "bNumEndpoints" = 2 | "bcdDevice" = 256 | } | +-o IOUSBMassStorageClass | { | "Write Time Out Duration" = 30000 | "Read Time Out Duration" = 30000 | "IOUnit" = 6 | "Physical Interconnect Location" = "External" | "CFBundleIdentifier" = "com.apple.iokit.IOUSBMassStorageClass" | "IOClass" = "IOUSBMassStorageClass" | "Protocol Characteristics" = {"Physical Interconnect"="USB","Physical Interconnect Location"="External","Read Time Out Duration"=30000,"Write Time Out Duration"=30000} | "IOProbeScore" = 50000 | "IOMatchCategory" = "IODefaultMatchCategory" | "bInterfaceSubClass" = 5 | "Physical Interconnect" = "USB" | "bInterfaceClass" = 8 | "IOProviderClass" = "IOUSBInterface" | "IOPowerManagement" = {"CurrentPowerState"=1,"DevicePowerState"=1,"ChildrenPowerState"=1,"DriverPowerState"=1} | } | +-o IOSCSIPeripheralDeviceNub | { | "IOProviderClass" = "IOSCSIProtocolServices" | "Protocol Characteristics" = {"Physical Interconnect"="USB","Physical Interconnect Location"="External","Read Time Out Duration"=30000,"Write Time Out Duration"=30000} | "IOMatchCategory" = "SCSITaskUserClientIniter" | "Product Revision Level" = "1000" | "IOProbeScore" = 0 | "Product Identification" = "Hi-MD WALKMAN" | "CFBundleIdentifier" = "com.apple.iokit.IOSCSIArchitectureModelFamily" | "Vendor Identification" = "SONY" | "IOClass" = "IOSCSIPeripheralDeviceNub" | "Peripheral Device Type" = 0 | } | +-o com_sony_driver_SonyMagicGate | { | "Vendor Identification" = "SONY" | "IOMaximumBlockCountWrite" = 64 | "Product Identification" = "Hi-MD WALKMAN" | "CFBundleIdentifier" = "com.sony.driver.SonyMagicGateDriver" | "IOClass" = "com_sony_driver_SonyMagicGate" | "Peripheral Device Type" = 0 | "IOMaximumByteCountWrite" = 131072 | "IOProbeScore" = 15000 | "IOMatchCategory" = "IODefaultMatchCategory" | "IOPowerManagement" = {"TimeSinceDeviceIdle"=15528947,"DevicePowerState"=0,"TimeSinceActivityTickle"=16129602,"ActivityTickles"=0,"DriverPowerState"=1,"CurrentPowerState"=1,"IdleTimerPeriod"=200000} | "IOMaximumBlockCountRead" = 64 | "IOProviderClass" = "IOSCSIPeripheralDeviceNub" | "IOMaximumByteCountRead" = 131072 | } | +-o com_sony_driver_SonyMagicGateNub | { | "IOMaximumSegmentCountRead" = 32 | "IOUserClientClass" = "SCSITaskUserClient" | "IOMatchCategory" = "SCSITaskUserClientIniter" | "Protocol Characteristics" = {"Physical Interconnect"="USB","Physical Interconnect Location"="External","Read Time Out Duration"=30000,"Write Time Out Duration"=30000} | "IOCFPlugInTypes" = {"7D66678E-08A2-11D5-A1B8-0030657D052A"="IOSCSIArchitectureModelFamily.kext/Contents/PlugIns/SCSITaskUserClient.kext/Contents/PlugIns/SCSITaskLib.plugin"} | "SCSITaskDeviceCategory" = "SonyMagicGateUserClientDevice" | "Device Characteristics" = {"Product Revision Level"="1000","Vendor Name"="SONY","Product Name"="Hi-MD WALKMAN"} | "IOMaximumSegmentCountWrite" = 32 | "IOMinimumSegmentAlignmentByteCount" = 4 | "device-type" = "Generic" | "SCSITaskUserClient GUID" = <8025d30592da5522a4690400> | } | +-o IOBlockStorageDriver | | { | | "IOProviderClass" = "IOBlockStorageDevice" | | "IOMatchCategory" = "IODefaultMatchCategory" | | "IOProbeScore" = 0 | | "Statistics" = {"Errors (Read)"=0,"Total Time (Write)"=80503124126,"Latency Time (Read)"=0,"Latency Time (Write)"=0,"Bytes (Read)"=1271808,"Retries (Read)"=0,"Bytes (Write)"=2301952,"Errors (Write)"=0,"Retries (Write)"=0,"Operations (Read)"=119,"Operations (Write)"=177,"Total Time (Read)"=31003860906} | | "IOPropertyMatch" = {"device-type"="Generic"} | | "IOGeneralInterest" = "IOCommand is not serializable" | | "CFBundleIdentifier" = "com.apple.iokit.IOStorageFamily" | | "IOClass" = "IOBlockStorageDriver" | | } | | | +-o SONY Hi-MD WALKMAN Media | | { | | "Leaf" = Yes | | "Writable" = Yes | | "BSD Minor" = 3 | | "IOBusyInterest" = "IOCommand is not serializable" | | "IOGeneralInterest" = "IOCommand is not serializable" | | "Preferred Block Size" = 2048 | | "BSD Major" = 14 | | "BSD Name" = "disk1" | | "Size" = 1011759104 | | "Content Hint" = "" | | "IOMediaIcon" = {"CFBundleIdentifier"="com.apple.iokit.IOStorageFamily","IOBundleResourceFile"="Removable.icns"} | | "Removable" = Yes | | "Open" = No | | "BSD Unit" = 1 | | "Whole" = Yes | | "Content" = "" | | "Ejectable" = Yes | | } | | | +-o IOMediaBSDClient | { | "IOResourceMatch" = "IOBSD" | "IOProbeScore" = 30000 | "IOMatchCategory" = "IOMediaBSDClient" | "CFBundleIdentifier" = "com.apple.iokit.IOStorageFamily" | "IOClass" = "IOMediaBSDClient" | "IOProviderClass" = "IOMedia" | } | +-o SCSITaskUserClientIniter { "IOProviderClass" = "com_sony_driver_SonyMagicGateNub" "IOMatchCategory" = "SCSITaskUserClientIniter" "IOProviderMergeProperties" = {"IOCFPlugInTypes"={"7D66678E-08A2-11D5-A1B8-0030657D052A"="IOSCSIArchitectureModelFamily.kext/Contents/PlugIns/SCSITaskUserClient.kext/Contents/PlugIns/SCSITaskLib.plugin"},"SCSITaskDeviceCategory"="SonyMagicGateUserClientDevice","IOUserClientClass"="SCSITaskUserClient"} "IOProbeScore" = 0 "CFBundleIdentifier" = "com.apple.iokit.SCSITaskUserClient" "IOPersonalityPublisher" = "com.sony.driver.SonyMagicGateDriver" "IOClass" = "SCSITaskUserClientIniter" } +-o ATADeviceNub@0 | { | "socket type" = "internal" | "device model" = "MATSHITADVD-R UJ-846 " | "IOUnit" = 0 | "IOMaximumSegmentCountRead" = 256 | "IOMaximumByteCountWrite" = 131072 | "device serial" = " " | "unit number" = 0 | "IOMaximumByteCountRead" = 131072 | "IOMaximumSegmentCountWrite" = 256 | "device revision" = "FM3J " | "ata device type" = "atapi" | } | +-o IOATAPIProtocolTransport | { | "ata device type" = "atapi" | "Write Time Out Duration" = 15000 | "Read Time Out Duration" = 15000 | "Physical Interconnect Location" = "Internal" | "CFBundleIdentifier" = "com.apple.iokit.IOATAPIProtocolTransport" | "Retry Count" = 1 | "IOClass" = "IOATAPIProtocolTransport" | "Protocol Characteristics" = {"unit number"=0} | "IOProbeScore" = 0 | "IOMatchCategory" = "IODefaultMatchCategory" | "Physical Interconnect" = "ATAPI" | "IOPowerManagement" = {"CurrentPowerState"=1,"DevicePowerState"=1,"ChildrenPowerState"=1,"DriverPowerState"=1} | "IOProviderClass" = "IOATADevice" | } | +-o IOSCSIPeripheralDeviceNub | { | "IOProviderClass" = "IOSCSIProtocolServices" | "Protocol Characteristics" = {"unit number"=0,"Physical Interconnect"="ATAPI","Retry Count"=1,"Physical Interconnect Location"="Internal","Read Time Out Duration"=15000,"Write Time Out Duration"=15000} | "IOMatchCategory" = "SCSITaskUserClientIniter" | "Product Revision Level" = "FM3J" | "IOProbeScore" = 0 | "Product Identification" = "DVD-R UJ-846" | "CFBundleIdentifier" = "com.apple.iokit.IOSCSIArchitectureModelFamily" | "Vendor Identification" = "MATSHITA" | "IOClass" = "IOSCSIPeripheralDeviceNub" | "Peripheral Device Type" = 5 | } | +-o IOSCSIPeripheralDeviceType05 | { | "IOMaximumBlockCountWrite" = 65535 | "CFBundleIdentifier" = "com.apple.iokit.IOSCSIMultimediaCommandsDevice" | "DVD Features" = 503 | "IOClass" = "IOSCSIPeripheralDeviceType05" | "Peripheral Device Type" = 5 | "IOProbeScore" = 5000 | "IOMatchCategory" = "IODefaultMatchCategory" | "CD Features" = 1791 | "IOPowerManagement" = {"TimeSinceDeviceIdle"=31721007,"DevicePowerState"=0,"TimeSinceActivityTickle"=32521010,"ActivityTickles"=0,"DriverPowerState"=1,"CurrentPowerState"=1,"IdleTimerPeriod"=200000} | "IOMaximumBlockCountRead" = 65535 | "IOProviderClass" = "IOSCSIPeripheralDeviceNub" | "BD Features" = 0 | } | +-o IODVDServices | { | "IOUserClientClass" = "SCSITaskUserClient" | "SCSITaskDeviceCategory" = "SCSITaskAuthoringDevice" | "IOMatchCategory" = "SCSITaskUserClientIniter" | "Protocol Characteristics" = {"unit number"=0,"Physical Interconnect"="ATAPI","Retry Count"=1,"Physical Interconnect Location"="Internal","Read Time Out Duration"=15000,"Write Time Out Duration"=15000} | "IOCFPlugInTypes" = {"97ABCF2C-23CC-11D5-A0E8-003065704866"="IOSCSIArchitectureModelFamily.kext/Contents/PlugIns/SCSITaskUserClient.kext/Contents/PlugIns/SCSITaskLib.plugin"} | "IOGeneralInterest" = "IOCommand is not serializable" | "Device Characteristics" = {"Loading Mechanism"="Slot","BD Features"=0,"Product Name"="DVD-R UJ-846","Product Revision Level"="FM3J","DVD Features"=503,"Async Notification"=No,"Vendor Name"="MATSHITA","Fast Spindown"=No,"Power Off"=No,"Low Power Polling"=Yes,"CD Features"=1791} | "IOMinimumSegmentAlignmentByteCount" = 4 | "device-type" = "DVD" | "SCSITaskUserClient GUID" = <8038680470ad544200000000> | } | +-o IODVDBlockStorageDriver | { | "IOProviderClass" = "IODVDBlockStorageDevice" | "IOMatchCategory" = "IODefaultMatchCategory" | "IOProbeScore" = 0 | "Statistics" = {"Errors (Read)"=4,"Total Time (Write)"=0,"Latency Time (Read)"=0,"Latency Time (Write)"=0,"Bytes (Read)"=231808,"Retries (Read)"=0,"Bytes (Write)"=0,"Errors (Write)"=0,"Retries (Write)"=0,"Operations (Read)"=116,"Operations (Write)"=0,"Total Time (Read)"=12148222507} | "IOPropertyMatch" = {"device-type"="DVD"} | "IOGeneralInterest" = "IOCommand is not serializable" | "CFBundleIdentifier" = "com.apple.iokit.IODVDStorageFamily" | "IOClass" = "IODVDBlockStorageDriver" | } | +-o SCSITaskUserClientIniter { "IOMatchCategory" = "SCSITaskUserClientIniter" "IOProviderMergeProperties" = {"IOCFPlugInTypes"={"97ABCF2C-23CC-11D5-A0E8-003065704866"="IOSCSIArchitectureModelFamily.kext/Contents/PlugIns/SCSITaskUserClient.kext/Contents/PlugIns/SCSITaskLib.plugin"},"SCSITaskDeviceCategory"="SCSITaskAuthoringDevice","IOUserClientClass"="SCSITaskUserClient"} "CFBundleIdentifier" = "com.apple.iokit.SCSITaskUserClient" "IOProbeScore" = 0 "IOClass" = "SCSITaskUserClientIniter" "IOProviderClass" = "IODVDServices" } From manner.moe@gmx.de Sat Dec 04 14:33:44 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POsFD-0005FD-6c>; Sat, 04 Dec 2010 14:33:43 +0100 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with smtp (envelope-from ) id <1POsFD-0007Xb-29>; Sat, 04 Dec 2010 14:33:43 +0100 Received: (qmail 25155 invoked by uid 0); 4 Dec 2010 13:33:42 -0000 Received: from 84.141.9.166 by www099.gmx.net with HTTP; Sat, 04 Dec 2010 14:33:41 +0100 (CET) Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Date: Sat, 04 Dec 2010 14:33:41 +0100 From: "Thomas Arp" Message-ID: <20101204133341.296270@gmx.net> MIME-Version: 1.0 To: linux-minidisc@lists.fu-berlin.de X-Authenticated: #17747474 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18x5mFwWJgxLqxiFGY/kn6x2MfNxpQK9relwkhINY d+ktgMTona+z41v86YMNPinKU9REM9ejVNIA== X-GMX-UID: BnTIfY9bIydmHjeremZrFCRSa2FkZlW3 X-Originating-IP: 213.165.64.23 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291469623-00000C0F-09D61CA4/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 13:33:44 -0000 >> Thanks a lot for investigating into that. I would very glad if we can >> drop libscg in favor of dvd+rw-tools. >I did not yet implement the suggested change, but I am quite confident >that it will work. I´m rewriting himdscsitest.c using the dvd-rw-tools headers for testing. As far as i have tested yet when cmd.transport() has finished the Scsi_Command structure will be closed automatically. If we want to send more commands we have to use cmd.associate(char * device) before sending another scsi command. Should we disable this autoclose feature and use genaral open and close commands instead or should every send-command function have it´s own Scsi_Command structure, so that we only need to give the devicename as parameter instead of a Scsi_Command structure? Thomas From glaubitz@physik.fu-berlin.de Sat Dec 04 14:38:58 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POsKH-0005Pv-65>; Sat, 04 Dec 2010 14:38:57 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POsKH-0001kC-4I>; Sat, 04 Dec 2010 14:38:57 +0100 Received: from div-8021x-dhcp107.uio.no ([193.157.176.116]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POsKG-0004vj-Vc>; Sat, 04 Dec 2010 14:38:57 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Glaubitz X-Priority: 3 In-Reply-To: <20101204133341.296270@gmx.net> Date: Sat, 4 Dec 2010 14:38:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101204133341.296270@gmx.net> To: "Thomas Arp" X-Mailer: Apple Mail (2.1082) X-Originating-IP: 193.157.176.116 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291469937-00000C0F-E545E4AF/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Algerien.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 13:38:58 -0000 Hi, On Dec 4, 2010, at 2:33 PM, Thomas Arp wrote: >>> Thanks a lot for investigating into that. I would very glad if we = can >>> drop libscg in favor of dvd+rw-tools. >> I did not yet implement the suggested change, but I am quite = confident >> that it will work. >=20 > I=B4m rewriting himdscsitest.c using the dvd-rw-tools headers for = testing. > As far as i have tested yet when cmd.transport() has finished the = Scsi_Command structure will be closed automatically. > If we want to send more commands we have to use cmd.associate(char * = device) before sending another scsi command. >=20 > Should we disable this autoclose feature and use genaral open and = close commands instead or should every send-command function have it=B4s = own Scsi_Command structure, so that we only need to give the devicename = as parameter instead of a Scsi_Command structure? What do you mean by disabling the feature? If I understood correctly, = one can use cmd.associate() instead of cmd.transport() to send subsequent commands to the device. If that's the = case, then I'd opt for the cmd.associate() version. Or are you talking about changing some code in the dvd+rw tools? Adrian= From glaubitz@physik.fu-berlin.de Sat Dec 04 14:44:09 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POsPI-0005az-71>; Sat, 04 Dec 2010 14:44:08 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POsPI-0002JO-3t>; Sat, 04 Dec 2010 14:44:08 +0100 Received: from div-8021x-dhcp107.uio.no ([193.157.176.116]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtpsa (envelope-from ) id <1POsPH-0005E9-Sh>; Sat, 04 Dec 2010 14:44:08 +0100 From: Adrian Glaubitz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Dec 2010 14:44:06 +0100 Message-Id: <632F9BEA-C6D7-44D6-95EE-89F7EA846AFB@physik.fu-berlin.de> To: Linux-Minidisc Mailinglist Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Originating-IP: 193.157.176.116 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291470248-00000C0F-1A1C74DB/0-0/0-0 X-Bogosity: Unsure, tests=bogofilter, spamicity=0.497945, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Dschibuti.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,FU_BOGO_UNSURE Subject: [linux-minidisc] Adding a wiki section regarding the legal issues X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 13:44:09 -0000 Hello, I was thinking today about adding a long and detailed section explaining the legal issues that are associated with our project to the wiki. Thus, = explaining the issues with the non-disclosable code and of SonicStage and OpenMG. The sole idea behind this section would be only to explain people why the software won't work out of the box with many MiniDisc devices and whom they could complain to in order to achieve a permission for full = disclosure from Sony =3D). If you guys agree, I would start on this section tonight. Adrian= From manner.moe@gmx.de Sat Dec 04 15:44:41 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POtLr-0007Tb-R3>; Sat, 04 Dec 2010 15:44:39 +0100 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with smtp (envelope-from ) id <1POtLr-0006iF-Mf>; Sat, 04 Dec 2010 15:44:39 +0100 Received: (qmail invoked by alias); 04 Dec 2010 14:44:39 -0000 Received: from dslc-082-083-147-052.pools.arcor-ip.net (EHLO MyHost) [82.83.147.52] by mail.gmx.net (mp008) with SMTP; 04 Dec 2010 15:44:39 +0100 X-Authenticated: #17747474 X-Provags-ID: V01U2FsdGVkX1+OFbQ24lKOWcE4ZSVEYtDbN1VoMSCkZJklgj0J+e L76WK1243NhYNF Date: Sat, 4 Dec 2010 15:44:36 +0100 Message-ID: <2250D269-275C-4953-A20C-6152DD3B6524@gmx.de> X-GeMail-Ref: From: manner.moe@gmx.de To: "Adrian Glaubitz" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-Mailer: GcMail 5.2.3.0(RG6) http://www.gcmail.de X-Y-GMX-Trusted: 0 X-Originating-IP: 213.165.64.22 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291473879-00000C0F-3BA62C4D/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Algerien.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=NO_REAL_NAME,SPF_HELO_PASS, SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: manner.moe@gmx.de List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 14:44:41 -0000 >Betreff : Re: [linux-minidisc] another way to send SCSI commands >Gesendet: 04.12.2010 14:38:54 >An : "Thomas Arp " >Von: "Adrian Glaubitz " >----- Originale Nachricht ----- >Hi, >On Dec 4, 2010, at 2:33 PM, Thomas Arp wrote: >>>> Thanks a lot for investigating into that. I would very glad if we can >>>> drop libscg in favor of dvd+rw-tools. >>> I did not yet implement the suggested change, but I am quite confident >>> that it will work. >> >> I´m rewriting himdscsitest.c using the dvd-rw-tools headers for testing. >> As far as i have tested yet when cmd.transport() has finished the Scsi_Command structure will be closed automatically. >> If we want to send more commands we have to use cmd.associate(char * device) before sending another scsi command. >> >> Should we disable this autoclose feature and use genaral open and close commands instead or should every send-command function have it´s own Scsi_Command structure, so that we only need to give the devicename as parameter instead of a Scsi_Command structure? >What do you mean by disabling the feature? If I understood correctly, one can use cmd.associate() instead of >cmd.transport() to send subsequent commands to the device. If that's the case, then I'd opt for the cmd.associate() >version. >Or are you talking about changing some code in the dvd+rw tools? >Adrian cmd.associate() opens a file handle to the given device name (at least on windows), this is to check if the devicename is valid scsi device. Then we can setup the cdb and send it with cmd.transport(). If cmd.transport() has finished the handle will be closed automatically. I think we should leave it as it is and every send-scsi-command function should call cmd.associate() first to check if the device is connected right before sending the command. If we make general open/close commands it could cause errors if the device is unplugged between opening the device and sending a scsi command. I will send my code of the test tool later, i have to rearrange it first. Thomas From glaubitz@physik.fu-berlin.de Sat Dec 04 17:10:58 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POuhN-0001h4-Ku>; Sat, 04 Dec 2010 17:10:57 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POuhN-0000xE-J0>; Sat, 04 Dec 2010 17:10:57 +0100 Received: from div-8021x-dhcp107.uio.no ([193.157.176.116]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POuhN-0003Ne-AT>; Sat, 04 Dec 2010 17:10:57 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Adrian Glaubitz In-Reply-To: <632F9BEA-C6D7-44D6-95EE-89F7EA846AFB@physik.fu-berlin.de> Date: Sat, 4 Dec 2010 17:10:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <632F9BEA-C6D7-44D6-95EE-89F7EA846AFB@physik.fu-berlin.de> To: Adrian Glaubitz X-Mailer: Apple Mail (2.1082) X-Originating-IP: 193.157.176.116 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291479057-00000C0F-1D015E05/0-0/0-0 X-Bogosity: Unsure, tests=bogofilter, spamicity=0.470001, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Dschibuti.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,FU_BOGO_UNSURE Cc: Linux-Minidisc Mailinglist Subject: Re: [linux-minidisc] Adding a wiki section regarding the legal issues X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:10:58 -0000 Hello, On Dec 4, 2010, at 2:44 PM, Adrian Glaubitz wrote: > Hello, >=20 > I was thinking today about adding a long and detailed section = explaining > the legal issues that are associated with our project to the wiki. = Thus, explaining > the issues with the non-disclosable code and of SonicStage and OpenMG. I have written a draft for this section and I also would like to publish = the official answers from Sony USA and Sony Japan. Here is the draft: = --------------------------------------------------------------------------= ------------------------------------ Legal Situation --------------- Sony uses a sophisticated DRM (digital rights management) system called = OpenMG in SonicStage and their NetMD and HiMD hardware to establish a secured = and controlled environment for dealing with digital content. OpenMG ensures that = digital content bought over their former online music store "Connect" or through the = purchase and subsequent ripping of audio CDs, is protected against unauthorized = copying and distribution. Since this content protection must also be maintained = when copying the music onto the NetMD/HiMD hardware, both use some kind of = encryption to transfer (NetMD) and store (HiMD) the content onto the media. This = means, that it is not possible to transfer content to and from the devices = without knowing these secret keys, i.e. alpha-numerical codes, from Sony which = are used to de- and encrypt the content. We have asked Sony for their kind = permission to disclose both these keys for NetMD and HiMD access into public so = that we can use the keys in our open source software, but unfortunately, they = did not grant us to do so. You can read the official statements from Sony = Japan here and Sony USA here. Without these keys, both our NetMD as well as = HiMD software has only limited transfer capabilities and the use of = additional, external keyfiles which provide these necessary keys are required. We do not provide these. = --------------------------------------------------------------------------= ------------------------------------ Any comments? Adrian= From Michael.Karcher@fu-berlin.de Sat Dec 04 18:23:23 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POvpR-0003uD-Fm>; Sat, 04 Dec 2010 18:23:21 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POvpR-000080-D6>; Sat, 04 Dec 2010 18:23:21 +0100 Received: from i59f7dea1.versanet.de ([89.247.222.161] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POvpR-0006fe-0l>; Sat, 04 Dec 2010 18:23:21 +0100 From: Michael Karcher To: Thomas Arp In-Reply-To: <20101204133341.296270@gmx.net> References: <20101204133341.296270@gmx.net> Content-Type: multipart/mixed; boundary="=-rW5oupDuBMDto3aRjth3" Date: Sat, 04 Dec 2010 18:23:41 +0100 Message-ID: <1291483421.6295.64.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-Originating-IP: 89.247.222.161 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291483401-00000C0F-7928525D/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002263, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Burundi.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: appro@fy.chalmers.se, linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 17:23:23 -0000 --=-rW5oupDuBMDto3aRjth3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit [Cc to the dvd+rw-tools again, as another patch is attached. BTW: Thanks for that lean code for that many OSsed! Andy: Please do not misunderstand this mail as trying to make your code look bad, even if I claim you violated some coding standard. I really appreciate your work, and the code you have written shows no problems if used correctly - it's just about prevention of abuse. This is of course something one doesn't have in mind if one writes a SCSI transfer toolkit for a single application instead of a general library. It's at least partly our "fault" to take code out of dvd+rw-tools and use it carelessly making our applications break.] Am Samstag, den 04.12.2010, 14:33 +0100 schrieb Thomas Arp: > I´m rewriting himdscsitest.c using the dvd-rw-tools headers for > testing. That's great! > As far as i have tested yet when cmd.transport() has finished the > Scsi_Command structure will be closed automatically. As far as I can see, this is neither the case for Windows nor for Linux. Can you point out the code you think it closes the file descriptor? I see closing only in the destructor of Scsi_Command, so the device is closed only when the Scsi_Command structure goes out of scope. But I *do* see a potential problem that causes early closes: The Scsi_Command structure must never be copied, as it violates the C++ "rule of three": http://en.wikipedia.org/wiki/Rule_of_three_%28C%2B%2B_programming%29 "must never be copied" is *not* talking about DRM here (SCNR), but means that you can not pass a "Scsi_Command" as value to a subfunction, because pass-by-value copies the data (and that includes the handle) to local storage of the subfunction, and if that subfunction terminates, the local copy is destructed, closing the handle, although the object it was copied from in the caller still is alive. Also hell will break loose (i.e. you will get early closed fds/double-closed fds/leaked fds) if you assign one Scsi_Command object to another one. So do only pass the Scsi_Command structure by reference or pointer! > Should we disable this autoclose feature and use genaral open and > close commands instead or should every send-command function have it´s > own Scsi_Command structure, so that we only need to give the > devicename as parameter instead of a Scsi_Command structure? Of course we don't want an autoclose feature, but I am very confident that what you observed was caused by copying Scsi_Command objects and using the object as intended wouldn't cause problems. I attach a patch to this mail that explicitly prohibits copying and assigment of Scsi_Command objects, so with the patched transport.hxx your program should fail to compile if it contains the problem I suppose. > Thomas Regards, Michael Karcher PS: Don't worry about Qt widget/dialog box classes you write violating the rule-of-three the same way. QObject itself is noncopyable (by defining an inaccessible copy-assignment operator and copy-constructor), so there already is an inherited user-defined copy constructor and assignment operator preventing problems. Cleanup in a destructor doesn't matter in this case. PS2: Of course "Scsi_Command_Is_Noncopyable" is reinventing the wheel. Boost already has boost::noncopyable and Qt has Q_DISABLY_COPY (although just for internal use) and thousands of other people wrote these 6 lines of code, too. But I don't want to pull boost into transport.hxx, as everyone who needed to install boost on Windows systems surely can understand. If our project already used boost, it would be a different story, of course. --=-rW5oupDuBMDto3aRjth3 Content-Disposition: attachment; filename="scsi-command-noncopyable.diff" Content-Type: text/x-patch; name="scsi-command-noncopyable.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- ../dvd+rw-tools-7.1/transport.hxx 2010-12-03 02:56:36.000000000 +0100 +++ transport.hxx 2010-12-04 18:17:57.000000000 +0100 @@ -136,6 +136,14 @@ return plusminus; } + +class Scsi_Command_Is_Noncopyable { + /* declare a private copy constructor and assignment operator */ + Scsi_Command_Is_Noncopyable(const Scsi_Command_Is_Noncopyable &); + Scsi_Command_Is_Noncopyable &operator=(const Scsi_Command_Is_Noncopyable &); +public: + Scsi_Command_Is_Noncopyable() {} +}; #if defined(__linux) @@ -205,7 +213,7 @@ { return rsm_open_device.f!=open; } #endif -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd,autoclose; char *filename; @@ -389,7 +397,7 @@ WRITE=SCCMD_WRITE } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd,autoclose; char *filename; @@ -510,7 +518,7 @@ WRITE=CAM_DIR_OUT } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd,autoclose; char *filename; @@ -701,7 +709,7 @@ WRITE=USCSI_WRITE } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd,autoclose; char *filename; @@ -920,7 +928,7 @@ WRITE=0 } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd; int autoclose; @@ -1077,7 +1085,7 @@ WRITE=DSRQ_WRITE } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int fd,autoclose; char *filename; @@ -1277,7 +1285,7 @@ unsigned char sense[18]; } SPKG; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: HANDLE fd; int autoclose; @@ -1449,7 +1457,7 @@ WRITE=kSCSIDataTransfer_FromInitiatorToTarget } Direction; -class Scsi_Command { +class Scsi_Command : public Scsi_Command_Is_Noncopyable { private: int autoclose,_timeout; char *filename; --=-rW5oupDuBMDto3aRjth3-- From Michael.Karcher@fu-berlin.de Sat Dec 04 18:26:37 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1POvsa-0003zx-LV>; Sat, 04 Dec 2010 18:26:36 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1POvsa-0000S2-JU>; Sat, 04 Dec 2010 18:26:36 +0100 Received: from i59f7dea1.versanet.de ([89.247.222.161] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1POvsa-0006oI-Dg>; Sat, 04 Dec 2010 18:26:36 +0100 From: Michael Karcher To: Adrian Glaubitz In-Reply-To: References: <632F9BEA-C6D7-44D6-95EE-89F7EA846AFB@physik.fu-berlin.de> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Dec 2010 18:26:57 +0100 Message-ID: <1291483617.6295.67.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Originating-IP: 89.247.222.161 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291483596-00000C0F-D02D0041/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.370243, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: Linux-Minidisc Mailinglist Subject: Re: [linux-minidisc] Adding a wiki section regarding the legal issues X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 17:26:37 -0000 Am Samstag, den 04.12.2010, 17:10 +0100 schrieb Adrian Glaubitz: > I have written a draft for this section and I also would like to publish the official > answers from Sony USA and Sony Japan. I don't know whether publishing the answers really is a good idea, but I think it should be no problem. > Legal Situation > --------------- > > Sony uses a sophisticated DRM (digital rights management) system called OpenMG > in SonicStage and their NetMD and HiMD hardware to establish a secured and controlled > environment for dealing with digital content. OpenMG ensures that digital content > bought over their former online music store "Connect" or through the purchase > and subsequent ripping of audio CDs, is protected against unauthorized copying > and distribution. Since this content protection must also be maintained when > copying the music onto the NetMD/HiMD hardware, both use some kind of encryption > to transfer (NetMD) and store (HiMD) the content onto the media. This means, > that it is not possible to transfer content to and from the devices without > knowing these secret keys, i.e. alpha-numerical codes, from Sony which are used > to de- and encrypt the content. We have asked Sony for their kind permission > to disclose both these keys for NetMD and HiMD access into public so that we > can use the keys in our open source software, but unfortunately, they did > not grant us to do so. You can read the official statements from Sony Japan > here and Sony USA here. Without these keys, both our NetMD as well as HiMD > software has only limited transfer capabilities and the use of additional, > external keyfiles which provide these necessary keys are required. We > do not provide these. This sounds very reasonable. Regards, Michael Karcher From Michael.Karcher@fu-berlin.de Sun Dec 05 01:55:09 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PP2se-0000p0-5o>; Sun, 05 Dec 2010 01:55:08 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PP2sc-00062o-UK>; Sun, 05 Dec 2010 01:55:07 +0100 Received: from i59f7dea1.versanet.de ([89.247.222.161] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PP2sa-0000aV-Nr>; Sun, 05 Dec 2010 01:55:06 +0100 From: Michael Karcher To: Adrian Glaubitz In-Reply-To: <1291417852.6295.36.camel@aquila> References: <1291343007.6070.22.camel@aquila> <4CC11874-AD13-4790-B8A4-9DEF5F9419DF@physik.fu-berlin.de> <1291417852.6295.36.camel@aquila> Content-Type: multipart/mixed; boundary="=-U2lgObdPYXGDdd8S1XeS" Date: Sun, 05 Dec 2010 01:55:33 +0100 Message-ID: <1291510533.6295.80.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-Originating-IP: 89.247.222.161 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291510508-00000C0F-87997270/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.119579, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: appro@fy.chalmers.se, linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 00:55:09 -0000 --=-U2lgObdPYXGDdd8S1XeS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Am Samstag, den 04.12.2010, 00:10 +0100 schrieb Michael Karcher: > > Thanks a lot for investigating into that. I would very glad if we can > > drop libscg in favor of dvd+rw-tools. > I did not yet implement the suggested change, but I am quite confident > that it will work. The attached patch makes sending an INQUIRY command to the attached Hi-MD walkman work. I did not test it with a CD drive yet (I might have broken that, although I doubt it), as the current design has the problem that it only works on drive with inserted media (as you specify the device using /dev/rdiskN, and this device does not exist if no medium is installed...) and the CD drive of the only Mac I have (remote) access to is currently empty. I will add later a function that allows specification of the IOKit device ID for attachment. Regards, Michael Karcher --=-U2lgObdPYXGDdd8S1XeS Content-Disposition: attachment; filename="mac-task-direct.diff" Content-Type: text/x-patch; name="mac-task-direct.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- transport.hxx.orig 2010-12-03 02:43:34.000000000 +0100 +++ transport.hxx 2010-12-05 01:50:29.000000000 +0100 @@ -1478,7 +1478,7 @@ io_object_t scsiob=IO_OBJECT_NULL,parent; CFMutableDictionaryRef match,bsddev; CFNumberRef num; - int i; + int i,res; if (ref) sb = *ref; else if (stat(file,&sb)) return 0; @@ -1511,32 +1511,51 @@ if ((scsiob = IOServiceGetMatchingService(kIOMasterPortDefault,match)) == IO_OBJECT_NULL) return !(errno=ENXIO); - // traverse up to "SCSITaskAuthoringDevice" + // Find a plugin of type MMCDeviceUserClientType or + // SCSITaskDeviceUserClientType by traversing the tree upwards. kern_return_t kret; + int found = 0; + CFStringRef mmctype = CFUUIDCreateString(kCFAllocatorDefault, + kIOMMCDeviceUserClientTypeID); + CFStringRef tasktype = CFUUIDCreateString(kCFAllocatorDefault, + kIOSCSITaskDeviceUserClientTypeID); while ((kret=IORegistryEntryGetParentEntry(scsiob,kIOServicePlane, - &parent)) == kIOReturnSuccess) - { CFStringRef uclient; - const char *s; - int cmp; + &parent)) == kIOReturnSuccess && !found) + { CFDictionaryRef plugins; IOObjectRelease(scsiob); scsiob = parent; - uclient = (CFStringRef)IORegistryEntryCreateCFProperty(scsiob, - CFSTR(kIOPropertySCSITaskDeviceCategory), + plugins = (CFDictionaryRef)IORegistryEntryCreateCFProperty(scsiob, + CFSTR(kIOCFPlugInTypesKey), kCFAllocatorDefault,0); - if (uclient) - { s = CFStringGetCStringPtr(uclient,kCFStringEncodingMacRoman); - cmp = strcmp(s,kIOPropertySCSITaskAuthoringDevice); - CFRelease(uclient); - if (cmp==0) break; + if (plugins) + { if (CFDictionaryContainsKey(plugins,mmctype)) + { res = attachViaMMC(scsiob); + found = 1; + } + if (CFDictionaryContainsKey(plugins,tasktype)) + { res = attachViaSCSITask(scsiob); + found = 1; + } + CFRelease(plugins); } } - if (kret!=kIOReturnSuccess) + CFRelease(tasktype); + CFRelease(mmctype); + if (!found) { if (scsiob!=IO_OBJECT_NULL) IOObjectRelease(scsiob); return !(errno=ENXIO); } + if (res) + { filename=strdup(file); + this->scsiob = scsiob; + } + return res; + } - SInt32 score=0; +private: + int attachViaMMC(io_object_t scsiob) + { SInt32 score=0; if (IOCreatePlugInInterfaceForService(scsiob, kIOMMCDeviceUserClientTypeID, kIOCFPlugInInterfaceID, @@ -1573,10 +1592,43 @@ return !(errno=EBUSY); } - filename=strdup(file); + return 1; + } + + int attachViaSCSITask(io_object_t scsiob) + { SInt32 score=0; + if (IOCreatePlugInInterfaceForService(scsiob, + kIOSCSITaskDeviceUserClientTypeID, + kIOCFPlugInInterfaceID, + &plugin,&score) != kIOReturnSuccess) + { IOObjectRelease(scsiob); + return !(errno=ENXIO); + } + if ((*plugin)->QueryInterface(plugin, + CFUUIDGetUUIDBytes(kIOSCSITaskDeviceInterfaceID), + (void**)&taskif) != S_OK) + { IODestroyPlugInInterface(plugin), plugin=NULL; + IOObjectRelease(scsiob); + return !(errno=ENXIO); + } + + // + // Note that in order to ObtainExclusiveAccess no corresponding + // /dev/[r]diskN may remain open by that time. For reference, + // acquiring exclusive access temporarily removes BSD block + // storage device from I/O registry as well as corresponding + // /dev entries. + // + if ((*taskif)->ObtainExclusiveAccess(taskif) != kIOReturnSuccess) + { (*taskif)->Release(taskif), taskif=NULL; + IODestroyPlugInInterface(plugin), plugin=NULL; + IOObjectRelease(scsiob), scsiob=IO_OBJECT_NULL; + return !(errno=EBUSY); + } return 1; } +public: unsigned char &operator[] (size_t i) { if (i==0) { memset (cdb,0,sizeof(cdb)); --=-U2lgObdPYXGDdd8S1XeS-- From manner.moe@gmx.de Sun Dec 05 04:57:27 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PP5j3-0006Ep-7E>; Sun, 05 Dec 2010 04:57:25 +0100 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with smtp (envelope-from ) id <1PP5j3-00085j-0o>; Sun, 05 Dec 2010 04:57:25 +0100 Received: (qmail invoked by alias); 05 Dec 2010 03:57:24 -0000 Received: from dslc-082-083-147-052.pools.arcor-ip.net (EHLO MyHost) [82.83.147.52] by mail.gmx.net (mp051) with SMTP; 05 Dec 2010 04:57:24 +0100 X-Authenticated: #17747474 X-Provags-ID: V01U2FsdGVkX1+dR0te0zydG7BEzAL5PXVMQqv1h6cYoY9/zX8jNQ mZYI3p6Z6iZ+Jx Date: Sun, 5 Dec 2010 04:57:22 +0100 Message-ID: X-GeMail-Ref: <1291483421.6295.64.camel@aquila> From: manner.moe@gmx.de To: "Michael Karcher" Content-Type: multipart/mixed; boundary="=_gcmail5" MIME-Version: 1.0 X-Mailer: GcMail 5.2.3.0(RG6) http://www.gcmail.de X-Y-GMX-Trusted: 0 X-Originating-IP: 213.165.64.23 X-ZEDAT-Hint: A X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291521445-00000C0F-8F903465/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000706, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=NO_REAL_NAME,SPF_HELO_PASS, SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: manner.moe@gmx.de List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 03:57:27 -0000 This is a multi-part message in MIME format --=_gcmail5 Content-Type: multipart/alternative; boundary="=_gcmail5_alt" --=_gcmail5_alt Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit >Betreff : Re: [linux-minidisc] another way to send SCSI commands >Gesendet: 04.12.2010 18:23:41 >An : "Thomas Arp " >Von: "Michael Karcher " >----- Originale Nachricht ----- >Am Samstag, den 04.12.2010, 14:33 +0100 schrieb Thomas Arp: >> I´m rewriting himdscsitest.c using the dvd-rw-tools headers for >> testing. >That's great! O.K., here is the new source code. >> As far as i have tested yet when cmd.transport() has finished the >> Scsi_Command structure will be closed automatically. >As far as I can see, this is neither the case for Windows nor for Linux. >Can you point out the code you think it closes the file descriptor? I >see closing only in the destructor of Scsi_Command, so the device is >closed only when the Scsi_Command structure goes out of scope. >But I *do* see a potential problem that causes early closes: The >Scsi_Command structure must never be copied, as it violates the C++ >"rule of three": > http://en.wikipedia.org/wiki/Rule_of_three_%28C%2B%2B_programming%29 >"must never be copied" is *not* talking about DRM here (SCNR), but means >that you can not pass a "Scsi_Command" as value to a subfunction, >because pass-by-value copies the data (and that includes the handle) to >local storage of the subfunction, and if that subfunction terminates, >the local copy is destructed, closing the handle, although the object it >was copied from in the caller still is alive. Also hell will break loose >(i.e. you will get early closed fds/double-closed fds/leaked fds) if you >assign one Scsi_Command object to another one. So do only pass the >Scsi_Command structure by reference or pointer! Yes, this was exactly my problem. Thomas --=_gcmail5_alt-- --=_gcmail5 Content-Type: application/octet-stream; name="himdscsitest_dvd-tools.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="himdscsitest_dvd-tools.cpp" LyoKICogICBoaW1kc2NzaXRlc3QuY3BwIC0gc2VuZCB2YXJpb3VzIFNDU0kgY29tbWFuZHMgdG8g SGlNRCBXYWxrbWFuCiAqCiAqIC0gc2VlIFdpa2k6IDxodHRwczovL3dpa2kucGh5c2lrLmZ1LWJl cmxpbi5kZS9saW51eC1taW5pZGlzYy9kb2t1LnBocD9pZD1oaW1kc2NzaT4KICogLSByZXF1aXJl cyB0cmFuc3BvcnQuaHh4LCBhc2N0YWJsZS5oIGFuZCB3aW4zMmVyci5oIGZyb20gZHZkK3J3LXRv b2xzIHBhY2thZ2UKICoKICovCgojaW5jbHVkZSA8dGltZS5oPgojaW5jbHVkZSA8c3RyaW5nPgoj aW5jbHVkZSA8Y2xpbWl0cz4KI2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8b3N0cmVhbT4K I2luY2x1ZGUgInRyYW5zcG9ydC5oeHgiCgojZGVmaW5lIFNDU0lfVEVTVF9VTklUX1JFQURZIDB4 MDAKI2RlZmluZSBTQ1NJX0lOUVVJUlkgMHgxMgojZGVmaW5lIFNDU0lfTE9BRF9VTkxPQUQgMHgx QgojZGVmaW5lIFNDU0lfQUxMT1dfUFJFVkVOVF9SRU1PVkFMIDB4MUUKI2RlZmluZSBTQ1NJX1JF QURfQ0FQQUNJVFkgMHgyNQojZGVmaW5lIFNDU0lfTUFJTlRFTkFOQ0VfT1VUX09SX1JFUE9SVF9L RVkgMHhBNAojZGVmaW5lIFNPTllfU1BFQ0lGSUNfQ09NTUFORCAweEMyCgojZGVmaW5lIEZPUk1B VF9FUkFTRV9GTEFHUyAzCiNkZWZpbmUgRk9STUFUX0hJTUQgMQojZGVmaW5lIEVSQVNFX0hJTUQg MAojZGVmaW5lIEdFVF9USU1FIDB4NTAKI2RlZmluZSBTRVRfVElNRSAweDkwCiNkZWZpbmUgQUxM T1dfUkVNT1ZBTCAwCiNkZWZpbmUgUFJFVkVOVF9SRU1PVkFMIDEKCiNkZWZpbmUgTUVESVVNXzYw X01JTiAyMzAKI2RlZmluZSBNRURJVU1fNzRfTUlOIDI4MwojZGVmaW5lIE1FRElVTV84MF9NSU4g MzA1CiNkZWZpbmUgTUVESVVNX0hJTURfMUdCIDEwMTEKCnVzaW5nIHN0ZDo6Y2VycjsKdXNpbmcg c3RkOjpjb3V0Owp1c2luZyBzdGQ6OmVuZGw7CgpzdGF0aWMgYm9vbCBpc19oaW1kX2RldmljZShT Y3NpX0NvbW1hbmQgJmNtZCkKewogICAgY2hhciBidWZmZXJbOTZdOwoKICAgIGNtZFswXSA9IFND U0lfSU5RVUlSWTsKCWNtZFs0XSA9IHNpemVvZihidWZmZXIpOwoJY21kWzVdID0gMDsKCiAgICBp ZihjbWQudHJhbnNwb3J0KFJFQUQsIGJ1ZmZlciwgc2l6ZW9mKGJ1ZmZlcikpKQogICAgewogICAg ICAgIGNlcnIgPDwgIkNhbm5vdCBnZXQgaW5xdWlyeSBkYXRhIjsKICAgICAgICByZXR1cm4gZmFs c2U7CiAgICB9CgogICAgaWYobWVtY21wKGJ1ZmZlcis4LCAiU09OWSIsIDQpID09IDAgJiYgbWVt Y21wKGJ1ZmZlcisxNiwgIkhpLU1EIFdBTEtNQU4iLCAxMykgPT0gMCkKICAgICAgICByZXR1cm4g dHJ1ZTsKCiAgICByZXR1cm4gZmFsc2U7Cn0KCnN0YXRpYyBpbnQgcmVhZF9jYXBhY2l0eShTY3Np X0NvbW1hbmQgJmNtZCkKewogICAgaW50IGJsb2NrcyA9IDAsIGJ5dGVzID0gMCwgcmV0OwogICAg ZG91YmxlIGRrYjsKICAgIHVuc2lnbmVkIGNoYXIgcmVzcG9uc2VbOF07CgogICAgY21kWzBdID0g U0NTSV9SRUFEX0NBUEFDSVRZOwogICAgY21kWzldID0gMDsKICAgIGlmKChyZXQgPSBjbWQudHJh bnNwb3J0KFJFQUQsIHJlc3BvbnNlLCBzaXplb2YocmVzcG9uc2UpKSkpCiAgICB7CiAgICAgICAg c3BlcnJvcigiUmVhZCBjYXBhY2l0eSIsIHJldCk7CiAgICAgICAgcmV0dXJuIDA7CiAgICB9Cgog ICAgYmxvY2tzID0gcmVzcG9uc2VbMF0qMTY3NzcyMTYrcmVzcG9uc2VbMV0qNjU1MzYrcmVzcG9u c2VbMl0qMjU2K3Jlc3BvbnNlWzNdOwogICAgYnl0ZXMgPSByZXNwb25zZVs0XSoxNjc3NzIxNity ZXNwb25zZVs1XSo2NTUzNityZXNwb25zZVs2XSoyNTYrcmVzcG9uc2VbN107CgogICAgZGtiID0g KGJsb2NrcyArIDEuMCkgKiAoYnl0ZXMvMTAyNC4wKTsKICAgIHJldHVybiAoZGtiLzEwMDAqMS4w MjQpOwp9CgpzdGF0aWMgaW50IHByZXZlbnRfcmVtb3ZhbChTY3NpX0NvbW1hbmQgJmNtZCwgaW50 IHByZXZlbnQpCnsKICAgIGNtZFswXSA9IFNDU0lfQUxMT1dfUFJFVkVOVF9SRU1PVkFMOwogICAg Y21kWzRdID0gcHJldmVudCAmIDE7CiAgICBjbWRbNV0gPSAwOwoKICAgIHJldHVybiBjbWQudHJh bnNwb3J0KCk7Cn0KCnN0YXRpYyBpbnQgdGVzdF91bml0X3JlYWR5KFNjc2lfQ29tbWFuZCAmY21k KQp7CiAgICBjbWRbMF0gPSBTQ1NJX1RFU1RfVU5JVF9SRUFEWTsKICAgIGNtZFs1XSA9IDA7CiAg ICByZXR1cm4gY21kLnRyYW5zcG9ydCgpOwp9CgpzdGF0aWMgdm9pZCByZWFkX3RpbWUoc3RydWN0 IHRtICogdG0sIGNvbnN0IGNoYXIgKiB0aW1lKQp7CiAgICB0bS0+dG1faXNkc3QgPSB0aW1lWzBd ICYgMHhmZjsKICAgIHRtLT50bV9zZWMgPSB0aW1lWzFdICYgMHhmZjsKICAgIHRtLT50bV9taW4g PSB0aW1lWzJdICYgMHhmZjsKICAgIHRtLT50bV9ob3VyID0gdGltZVszXSAmIDB4ZmY7CiAgICB0 bS0+dG1fbWRheSA9IHRpbWVbNF0gJiAweGZmOwogICAgdG0tPnRtX21vbiA9IHRpbWVbNV0gJiAw eGZmOwogICAgdG0tPnRtX3llYXIgPSB0aW1lWzZdICYgMHhmZjsKCiAgICBta3RpbWUodG0pOyAv KiB0aGlzIHdpbGwgc2V0IHRtX3dkYXkgYW5kIHRtX3lkYXkgY29ycmVjdGx5Ki8KfQoKaW50IGZv cm1hdF9tZWRpdW0oU2NzaV9Db21tYW5kICZjbWQsIGludCBjYXApCnsKICAgIGludCByZXQ7Cgog ICAgY21kWzBdID0gU09OWV9TUEVDSUZJQ19DT01NQU5EOwogICAgY21kWzNdID0gRk9STUFUX0hJ TUQ7CiAgICBjbWRbNF0gPSBGT1JNQVRfRVJBU0VfRkxBR1M7CiAgICBjbWRbMTFdID0gMDsKCiAg ICBpZihjYXAgPT0gMCkKICAgIHsKICAgICAgICBjZXJyIDw8ICJFcnJvcjogQ2Fubm90IHJlYWQg Y2FwYWNpdHkiOwogICAgICAgIHJldHVybiAwOwogICAgfQoKICAgIGlmKChyZXQgPSBjbWQudHJh bnNwb3J0KCkpKQogICAgewogICAgICAgIHNwZXJyb3IoIkZvcm1hdCBoaW1kIiwgcmV0KTsKICAg ICAgICByZXR1cm4gMDsKICAgIH0KCiAgICBjb3V0IDw8ICJQbGVhc2Ugd2FpdCwgZm9ybWF0dGlu ZyBkZXZpY2UuIiA8PCBlbmRsOwogICAgcmV0dXJuIDE7Cgp9CgppbnQgZXJhc2VfbWVkaXVtKFNj c2lfQ29tbWFuZCAmY21kLCBpbnQgY2FwKQp7CiAgICBpbnQgcmV0OwoKICAgIGNtZFswXSA9IFNP TllfU1BFQ0lGSUNfQ09NTUFORDsKICAgIGNtZFszXSA9IEVSQVNFX0hJTUQ7CiAgICBjbWRbNF0g PSBGT1JNQVRfRVJBU0VfRkxBR1M7CiAgICBjbWRbMTFdID0gMDsKCiAgICBpZihjYXAgPT0gMCkK ICAgIHsKICAgICAgICBjb3V0IDw8ICJFcnJvcjogQ2Fubm90IHJlYWQgY2FwYWNpdHkiIDw8IGVu ZGw7CiAgICAgICAgcmV0dXJuIDA7CiAgICB9CiAgICBlbHNlIGlmKGNhcCA9PSBNRURJVU1fSElN RF8xR0IpCiAgICB7CiAgICAgICAgY291dCA8PCAiRXJyb3I6IEVyYXNpbmcgMUdCIEhpTUQgbWVk aXVtIGlzIG5vdCBzdXBwb3J0ZWQiIDw8IGVuZGwgPDwKICAgICAgICAgICAgICAgICJQbGVhc2Ug dXNlIGZvcm1hdCB0byBkZWxldGUgYWxsIHRyYWNrcy4iIDw8IGVuZGw7CiAgICAgICAgcmV0dXJu IDA7Cgl9CgogICAgaWYoKHJldCA9IGNtZC50cmFuc3BvcnQoKSkpCiAgICB7CiAgICAgICAgc3Bl cnJvcigiRXJhc2UgaGltZCIsIHJldCk7CiAgICAgICAgcmV0dXJuIDA7Cgl9CiAgICBjb3V0IDw8 ICJQbGVhc2Ugd2FpdCwgd2hpbGUgZXJhc2luZyBtZWRpdW0uIiA8PCBlbmRsOwogICAgcmV0dXJu IDE7Cn0KCnZvaWQgZ2V0X2Rpc2NfaWQoU2NzaV9Db21tYW5kICZjbWQpCnsKICAgIHVuc2lnbmVk IGNoYXIgYnVmZmVyWzE4XTsKICAgIGludCBpLCByZXQ7CgogICAgY21kWzBdID0gU0NTSV9NQUlO VEVOQU5DRV9PVVRfT1JfUkVQT1JUX0tFWTsKICAgIGNtZFs3XSA9IDB4QkQ7CiAgICBjbWRbOV0g PSBzaXplb2YoYnVmZmVyKTsKICAgIGNtZFsxMF0gPSAweDNEOwogICAgY21kWzExXSA9IDA7Cgog ICAgbWVtc2V0KGJ1ZmZlciwgMCwgc2l6ZW9mKGJ1ZmZlcikpOwoKICAgIGlmKChyZXQgPSBjbWQu dHJhbnNwb3J0KFJFQUQsIGJ1ZmZlciwgc2l6ZW9mKGJ1ZmZlcikpKSkKICAgIHsKICAgICAgICBz cGVycm9yKCJSZWFkIGRpc2MgaWQiLCByZXQpOwogICAgICAgIHJldHVybjsKICAgIH0KCiAgICBj b3V0IDw8ICJEaXNjIElEOiAiOwogICAgZm9yKGkgPSAyO2kgPCAweDEyOysraSkKICAgICAgICBm cHJpbnRmKHN0ZG91dCwgIiUwMngiLCBidWZmZXJbaV0pOwogICAgY291dCA8PCBlbmRsOwp9Cgp2 b2lkIGdldF90aW1lKFNjc2lfQ29tbWFuZCAmY21kKQp7CiAgICBjaGFyIGJ1ZmZlcls3XTsKICAg IHN0cnVjdCB0bSB0bTsKICAgIGludCByZXQ7CgogICAgY21kWzBdID0gU09OWV9TUEVDSUZJQ19D T01NQU5EOwogICAgY21kWzNdID0gR0VUX1RJTUU7CiAgICBjbWRbOF0gPSBzaXplb2YoYnVmZmVy KTsKICAgIGNtZFsxMV0gPSAwOwoKICAgIGlmKChyZXQgPSBjbWQudHJhbnNwb3J0KFJFQUQsIGJ1 ZmZlciwgc2l6ZW9mKGJ1ZmZlcikpKSkKICAgIHsKICAgICAgICBzcGVycm9yKCJSZWFkIGRldmlj ZSB0aW1lIiwgcmV0KTsKICAgICAgICByZXR1cm47CiAgICB9CgogICAgcmVhZF90aW1lKCZ0bSwg YnVmZmVyKTsKICAgIGZwcmludGYoc3RkZXJyLCAiRGV2aWNlIHRpbWUgaXM6ICVzXG4iLCBhc2N0 aW1lKCZ0bSkpOwp9Cgp2b2lkIHNldF9sb2NhbHRpbWUoU2NzaV9Db21tYW5kICZjbWQpCnsKICAg IHRpbWVfdCB0ID0gdGltZShOVUxMKTsKICAgIHN0cnVjdCB0bSAqIHRtZTsKICAgIGludCByZXQ7 CgogICAgaWYodCA9PSAtMSkKICAgIHsKICAgICAgICBjb3V0IDw8ICJFcnJvcjogQ2Fubm90IGdl dCBsb2NhbCB0aW1lLiIgPDwgZW5kbDsKICAgICAgICByZXR1cm47CiAgICB9CgogICAgdG1lID0g bG9jYWx0aW1lKCZ0KTsKICAgIGNvdXQgPDwgIlJlYWRpbmcgbG9jYWwgY29tcHV0ZXIgdGltZTog IiA8PCBhc2N0aW1lKHRtZSkgPDwgZW5kbDsKCiAgICBjbWRbMF0gPSBTT05ZX1NQRUNJRklDX0NP TU1BTkQ7CiAgICBjbWRbM10gPSBTRVRfVElNRTsKICAgIGNtZFs1XSA9IHRtZS0+dG1fc2VjICYg MHhmZjsKICAgIGNtZFs2XSA9IHRtZS0+dG1fbWluICYgMHhmZjsKICAgIGNtZFs3XSA9IHRtZS0+ dG1faG91ciAmIDB4ZmY7CiAgICBjbWRbOF0gPSB0bWUtPnRtX21kYXkgJiAweGZmOwogICAgY21k WzldID0gdG1lLT50bV9tb24gJiAweGZmOwogICAgY21kWzEwXSA9IHRtZS0+dG1feWVhciAmIDB4 ZmY7CiAgICBjbWRbMTFdID0gMDsKCiAgICBpZigocmV0ID0gY21kLnRyYW5zcG9ydCgpKSkKICAg ICAgICBzcGVycm9yKCJTZXQgZGV2aWNlIHRpbWUiLCByZXQpOwogICAgZWxzZQogICAgICAgIGNv dXQgPDwgIlRpbWUgc3VjY2Vzc2Z1bGx5IHNldC4iIDw8IGVuZGw7Cn0KCnZvaWQgZWplY3RfbWVk aXVtKFNjc2lfQ29tbWFuZCAmY21kKQp7CiAgICBpbnQgcmV0OwoKICAgIHByZXZlbnRfcmVtb3Zh bChjbWQsIEFMTE9XX1JFTU9WQUwpOwoKICAgIGNtZFswXSA9IFNDU0lfTE9BRF9VTkxPQUQ7CiAg ICBjbWRbNF0gPSAyOwogICAgY21kWzVdID0gMDsKCiAgICBpZigocmV0ID0gY21kLnRyYW5zcG9y dCgpKSkKICAgICAgICBzcGVycm9yKCJFamVjdCBtZWRpdW0iLCByZXQpOwp9Cgp2b2lkIHVzYWdl KGNoYXIgKiBjbWRuYW1lKQp7CiAgcHJpbnRmKCJVc2FnZTogJXMgPGRldmljZW5hbWU+IDxjb21t YW5kPiwgd2hlcmUgPGNvbW1hbmQ+IGlzIGVpdGhlciBvZjpcblxuXAogICAgICAgICAgZm9ybWF0 ICAgICAgIC0gZXJhc2VzIGFsbCB0cmFja3Mgb24gZGlzY1xuXAogICAgICAgICAgZXJhc2UgICAg ICAgIC0gZXJhc2VzIGFsbCB0cmFja3MgYW5kIGhpbWQgZmlsZSBzeXN0ZW0gKG5vdCBvbSAxR0Ig bWVkaXVtKVxuXAogICAgICAgICAgZGlzY2lkICAgICAgIC0gcmVhZHMgdGhlIGRpc2MgaWQgb2Yg dGhlIGluc2VydGVkIG1lZGl1bVxuXAogICAgICAgICAgZ2V0dGltZSAgICAgIC0gcmVhZHMgdGhl IHRpbWUgb2YgZGV2aWNlIGludGVybmFsIGNsb2NrXG5cCiAgICAgICAgICBzZXRsb2NhbHRpbWUg LSBzeW5jcyBkZXZpY2UgaW50ZXJuYWwgY2xvY2sgd2l0aCB5b3VyIGxvY2FsIGNvbXB1dGVyIHRp bWVcblwKICAgICAgICAgIGNhcGFjaXR5ICAgICAtIHNob3dzIHRoZSBjYXBhY2l0eSBvZiBpbnNl cnRlZCBtZWRpdW0gaW4gTUJcblwKICAgICAgICAgIGVqZWN0ICAgICAgICAtIGVqZWN0cyB0aGUg bWVkaXVtIChzYW1lIGFzIHByZXNzaW5nIHN0b3AgYnV0dG9uIG9uIGRldmljZSlcbiIsIGNtZG5h bWUpOwp9CgppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKiBhcmd2KQp7CiAgICBTY3NpX0NvbW1h bmQgY21kOwogICAgY2hhciByZXNwb25zZVs5Nl07CiAgICBpbnQgY2FwYWNpdHk7CgogICAgaWYg KGFyZ2MgPT0gMiAmJiAoc3RyY21wIChhcmd2WzFdLCAiaGVscCIpID09IDApKSB7CiAgICAgICAg dXNhZ2UoYXJndlswXSk7CiAgICAgICAgcmV0dXJuIDA7CiAgICB9CgogICAgaWYgKGFyZ2MgIT0g MykgewogICAgICAgIHByaW50ZigiUGxlYXNlIHNwZWNpZnkgZGV2aWNlIG5hbWUgYW5kIGNvbW1h bmQgdG8gYmUgc2VudC4gVXNlIFwiJXMgaGVscFwiIHRvIGRpc3BsYXkgYSBoZWxwLlxuIiwgYXJn dlswXSk7CiAgICAgICAgcmV0dXJuIDA7CiAgICB9CgogICAgaWYoIWNtZC5hc3NvY2lhdGUoYXJn dlsxXSkpCiAgICB7CiAgICAgICAgY2VyciA8PCAiQ2FuJ3QgYXNzb2NpYXRlIjsKICAgICAgICBy ZXR1cm4gMTsKICAgIH0KCiAgICBpZih0ZXN0X3VuaXRfcmVhZHkoY21kKSkKICAgIHsKICAgICAg ICBjZXJyIDw8ICJFcnJvcjogZGV2aWNlIGJ1c3kiOwogICAgICAgIHJldHVybiAxOwogICAgfQoK ICAgIGlmKCFpc19oaW1kX2RldmljZShjbWQpKQogICAgewogICAgICAgIGNlcnIgPDwgIkVycm9y OiBEZXZpY2UgaXMgbm90IGEgaGltZCBkZXZpY2UiOwogICAgICAgIHJldHVybiAxOwogICAgfQoK ICAgIGNhcGFjaXR5ID0gcmVhZF9jYXBhY2l0eShjbWQpOwogICAgcHJldmVudF9yZW1vdmFsKGNt ZCwgUFJFVkVOVF9SRU1PVkFMKTsKCiAgICBpZihzdHJjbXAoYXJndlsyXSwiZm9ybWF0IikgPT0g MCkgICAgICAgICAgICAgLyogYWthICJFcmFzZSBBbGwiLCBkZWxldGVzIGFsbCB0cmFja3MgYnV0 IGxlYXZlcyAqLwogICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8qIGhpbWQgZmlsZSBzeXN0ZW0gb24gZGlzYyAgICAgICAgICAgICAgICAgICAgICAgKi8K ICAgICAgICBpZihmb3JtYXRfbWVkaXVtKGNtZCwgY2FwYWNpdHkpKQogICAgICAgIHsKICAgICAg ICAgICAgd2FpdF9mb3JfdW5pdChjbWQpOwogICAgICAgICAgICBjb3V0IDw8ICJIaU1EIHN1Y2Nl c3NmdWxseSBmb3JtYXR0ZWQuIiA8PCBlbmRsOwogICAgICAgIH0KICAgIH0KCiAgICBlbHNlIGlm KHN0cmNtcChhcmd2WzJdLCJlcmFzZSIpID09IDApICAgICAgIC8qIGRlbGV0ZXMgYWxsIGluY2wu IGhpbWQgZmlsZSBzeXN0ZW0sICovCiAgICB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8qIHdpbGwgbm90IHdvcmsgb24gMUdCIGhpbWQgbWVkaWEgICovCiAgICAg ICAgaWYoZXJhc2VfbWVkaXVtKGNtZCwgY2FwYWNpdHkpKQogICAgICAgIHsKICAgICAgICAgICAg d2FpdF9mb3JfdW5pdChjbWQpOwogICAgICAgICAgICBjb3V0IDw8ICJIaU1EIHN1Y2Nlc3NmdWxs eSBlcmFzZWQuIiA8PCBlbmRsOwogICAgICAgIH0KICAgIH0KCiAgICBlbHNlIGlmKHN0cmNtcChh cmd2WzJdLCJkaXNjaWQiKSA9PSAwKQogICAgICAgIGdldF9kaXNjX2lkKGNtZCk7CgogICAgZWxz ZSBpZihzdHJjbXAoYXJndlsyXSwiZ2V0dGltZSIpID09IDApCiAgICAgICAgZ2V0X3RpbWUoY21k KTsKCiAgICBlbHNlIGlmKHN0cmNtcChhcmd2WzJdLCJzZXRsb2NhbHRpbWUiKSA9PSAwKQogICAg ICAgIHNldF9sb2NhbHRpbWUoY21kKTsKCiAgICBlbHNlIGlmKHN0cmNtcChhcmd2WzJdLCJjYXBh Y2l0eSIpID09IDApCiAgICB7CiAgICAgICAgaWYoY2FwYWNpdHkgIT0gMCkKICAgICAgICAgICAg Y291dCA8PCAiQ2FwYWNpdHk6ICIgPDwgY2FwYWNpdHkgPDwgIiBNQiIgPDwgZW5kbDsKICAgICAg ICBlbHNlCiAgICAgICAgICAgIGNlcnIgPDwgIkVycm9yOiBDYW5ub3QgcmVhZCBjYXBhY2l0eSI7 CiAgICB9CiAgICBlbHNlIGlmKHN0cmNtcChhcmd2WzJdLCJlamVjdCIpID09IDApCiAgICAgICAg ZWplY3RfbWVkaXVtKGNtZCk7CiAgICBlbHNlCiAgICB7CiAgICAgICAgdXNhZ2UgKGFyZ3ZbMF0p OwogICAgICAgIHJldHVybiAxOwogICAgfQoKICAgIHByZXZlbnRfcmVtb3ZhbChjbWQsIEFMTE9X X1JFTU9WQUwpOwoKICAgIHJldHVybiAwOwp9Cg== --=_gcmail5-- From adrian.glaubitz@googlemail.com Mon Dec 06 00:43:02 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPOEP-0000TD-5n>; Mon, 06 Dec 2010 00:43:01 +0100 Received: from mail-ey0-f182.google.com ([209.85.215.182]) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPOEP-0001xk-3D>; Mon, 06 Dec 2010 00:43:01 +0100 Received: by eyb7 with SMTP id 7so6189452eyb.13 for ; Sun, 05 Dec 2010 15:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Cdwz4X2dwMZIEcJfna4i8AigSMbYNVSDfMNsQxc/7Fw=; b=W/5dnTOlaMb3/OHdGZlVOAU2ENvpjYvRVc8wz1lygaoex0HnV7N8Dl3mleTIvZ4aUL aBLfqERrrEipR6yNLoqEks2Dt91ymdBCleKvrdCWdqIKrQOg9h4Fw9mC++4XDa4Hl/Qf rbaU7e3GjGoFpbU8Tsejp9O8flGT9rEEw7OLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=umLxp3WAF2+89WlaHUh7bGx4xdFIIY0sT2dSGUPnWU20Q5PfrRoyYB9g35h4CSW/7C MwIwmW0aXbUGXZTc+CbqGCfeIMiBf8ybCmXIgxY96niv5ma21g/oQ/cWyOgPZglTnD4l y45R36n5jqdxMWSyKr7vJScND+Yp2uTYd0k3I= Received: by 10.14.45.78 with SMTP id o54mr3582051eeb.41.1291592580784; Sun, 05 Dec 2010 15:43:00 -0800 (PST) Received: from kri3-1x-dhcp348.studby.uio.no (kri3-1x-dhcp348.studby.uio.no [193.157.241.96]) by mx.google.com with ESMTPS id q58sm4098060eeh.9.2010.12.05.15.42.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 05 Dec 2010 15:43:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Glaubitz In-Reply-To: Date: Mon, 6 Dec 2010 00:42:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: manner.moe@gmx.de X-Mailer: Apple Mail (2.1082) X-Originating-IP: 209.85.215.182 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291592581-00000C0F-DCC6DB82/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.-Berlin.DE X-Spam-Level: x X-Spam-Status: No, score=1.8 required=5.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS Cc: Michael Karcher , linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 23:43:02 -0000 Hi, On Dec 5, 2010, at 4:57 AM, manner.moe@gmx.de wrote: >> Am Samstag, den 04.12.2010, 14:33 +0100 schrieb Thomas Arp: >>> I=B4m rewriting himdscsitest.c using the dvd-rw-tools headers for >>> testing. >> That's great! >=20 > O.K., here is the new source code. Without going yet into detail, two questions: - Is this source Windows-specific? ("- requires [...] win32err.h") - What are the requirements to get the code compile? does one simply need the headers? Usually using such a library involves linking against a .lib file. Or is it just transport.hxx which contains most of the code? Adrian From Michael.Karcher@fu-berlin.de Mon Dec 06 00:58:45 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPOTc-0001Ci-Pp>; Mon, 06 Dec 2010 00:58:44 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PPOTc-0001QT-H0>; Mon, 06 Dec 2010 00:58:44 +0100 Received: from i59f7e589.versanet.de ([89.247.229.137] helo=[192.168.0.24]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PPOTU-00021m-TQ>; Mon, 06 Dec 2010 00:58:44 +0100 From: Michael Karcher To: Adrian Glaubitz In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Dec 2010 00:59:12 +0100 Message-ID: <1291593552.6295.86.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Originating-IP: 89.247.229.137 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291593524-00000C0F-EB54AAEE/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000040, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Dschibuti.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 23:58:45 -0000 Am Montag, den 06.12.2010, 00:42 +0100 schrieb Adrian Glaubitz: > Without going yet into detail, two questions: > > - Is this source Windows-specific? ("- requires [...] win32err.h") That header is only required on Windows. It is included in dvd+rw-tools. > - What are the requirements to get the code compile? does > one simply need the headers? Right. > Or is it just transport.hxx which contains most of the code? Exactly this. Quoting myself: "The whole implementation is currently inside a header file, so you can't avoid to to have it linked into your program." > Adrian Regards, Michael Karcher From manner.moe@gmx.de Mon Dec 06 01:00:47 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPOVa-0001Xu-9k>; Mon, 06 Dec 2010 01:00:46 +0100 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with smtp (envelope-from ) id <1PPOVa-0004A5-5O>; Mon, 06 Dec 2010 01:00:46 +0100 Received: (qmail invoked by alias); 06 Dec 2010 00:00:46 -0000 Received: from dslc-082-083-147-052.pools.arcor-ip.net (EHLO MyHost) [82.83.147.52] by mail.gmx.net (mp007) with SMTP; 06 Dec 2010 01:00:46 +0100 X-Authenticated: #17747474 X-Provags-ID: V01U2FsdGVkX19lDo0g5f1lonwwWiaAPa+/nEOjXDdcaVB5MdR9il CL5QNIQ4+B1/h2 Date: Mon, 6 Dec 2010 01:01:48 +0100 Message-ID: X-GeMail-Ref: From: manner.moe@gmx.de To: "Adrian Glaubitz" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-Mailer: GcMail 5.2.3.0(RG6) http://www.gcmail.de X-Y-GMX-Trusted: 0 X-Originating-IP: 213.165.64.23 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291593646-00000C0F-CE9E5E63/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Botsuana.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=NO_REAL_NAME,SPF_HELO_PASS, SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: manner.moe@gmx.de List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 00:00:47 -0000 >Betreff : Re: [linux-minidisc] another way to send SCSI commands >Gesendet: 06.12.2010 00:42:59 >An : "manner.moe@gmx.de" >Von: "Adrian Glaubitz " >----- Originale Nachricht ----- >Hi, >On Dec 5, 2010, at 4:57 AM, manner.moe@gmx.de wrote: >>> Am Samstag, den 04.12.2010, 14:33 +0100 schrieb Thomas Arp: >>>> I´m rewriting himdscsitest.c using the dvd-rw-tools headers for >>>> testing. >>> That's great! >> >> O.K., here is the new source code. >Without going yet into detail, two questions: >- Is this source Windows-specific? ("- requires [...] win32err.h") >- What are the requirements to get the code compile? does > one simply need the headers? Usually using such a library > involves linking against a .lib file. Or is it just transport.hxx > which contains most of the code? >Adrian This source code is complete platform independent. You only need to include transport.hxx, win32err.h will be included by transport.hxx on win32 platform only and asctable.h will be included by transport.hxx on any platform. You don´t need win32err.h on linux or mac. And you don´t need to link to any library because there is no library, all classes/functions are implemented in transport.hxx. Thomas From adrian.glaubitz@googlemail.com Mon Dec 06 11:35:20 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPYPf-0004j6-K2>; Mon, 06 Dec 2010 11:35:19 +0100 Received: from mail-ey0-f182.google.com ([209.85.215.182]) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPYPf-0003Ms-GB>; Mon, 06 Dec 2010 11:35:19 +0100 Received: by eyb7 with SMTP id 7so6321272eyb.13 for ; Mon, 06 Dec 2010 02:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=7JRCCrjdM1ugRwFeDpkd4lSr6yV2UcirQF8qH6Ohy+A=; b=Mt8wLPHqbTM+wS0hA6KXH/lGJZbSFfZAX1L++6PTRquE+4aiMBrjnWpGRkC3QJJ2Ia sFlcK9vQpTrMuni0YdZQOL2T/5UzX4gQNkSiMMiAkFSN2x/BbDOs6qiyY6da0tBAQtCN D+uT0e0Erb1BBs55BzR99MECu2UN4FO1MyNQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YJTtdUSBim+eP1txBgouTbHP4vz30h8w3TbVnw5n7AcUVJVfoqLWeVRnWlg3bHEeh/ YpAsq6DKhoZZBiDfgMKt5lwB0uxnrbRbBbIQdSn91oQrUvSY+nl6k90gxn6qbxljttTH KXC8fhqvNcWUVH334VoqZKB8opMkYTvjiLMrw= Received: by 10.14.37.79 with SMTP id x55mr4144614eea.16.1291631719168; Mon, 06 Dec 2010 02:35:19 -0800 (PST) Received: from div-8021x-dhcp107.uio.no (div-8021x-dhcp107.uio.no [193.157.176.116]) by mx.google.com with ESMTPS id q58sm4577769eeh.3.2010.12.06.02.35.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 02:35:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Adrian Glaubitz In-Reply-To: <1291593552.6295.86.camel@aquila> Date: Mon, 6 Dec 2010 11:35:17 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <1291593552.6295.86.camel@aquila> To: Michael Karcher X-Mailer: Apple Mail (2.1082) X-Originating-IP: 209.85.215.182 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291631719-00000C0F-9E58F7BD/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Algerien.ZEDAT.-Berlin.DE X-Spam-Level: x X-Spam-Status: No, score=1.8 required=5.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 10:35:20 -0000 On Dec 6, 2010, at 12:59 AM, Michael Karcher wrote: > Am Montag, den 06.12.2010, 00:42 +0100 schrieb Adrian Glaubitz: >> Without going yet into detail, two questions: >> >> - Is this source Windows-specific? ("- requires [...] win32err.h") > That header is only required on Windows. It is included in dvd+rw-tools. > >> - What are the requirements to get the code compile? does >> one simply need the headers? > Right. >> Or is it just transport.hxx which contains most of the code? > Exactly this. Quoting myself: "The whole implementation is currently > inside a header file, so you can't avoid to to have it linked into your > program." Then, why isn't it committed to the git tree yet? =) If the code works fine, please don't hesitate to commit it and credit Thomas. Adrian From manner.moe@gmx.de Mon Dec 06 17:54:42 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPeKn-0001XT-Pe>; Mon, 06 Dec 2010 17:54:41 +0100 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with smtp (envelope-from ) id <1PPeKn-0001yK-LE>; Mon, 06 Dec 2010 17:54:41 +0100 Received: (qmail invoked by alias); 06 Dec 2010 16:54:41 -0000 Received: from dslc-082-083-147-052.pools.arcor-ip.net (EHLO MyHost) [82.83.147.52] by mail.gmx.net (mp036) with SMTP; 06 Dec 2010 17:54:41 +0100 X-Authenticated: #17747474 X-Provags-ID: V01U2FsdGVkX18o+mYeJLYo2pg7RMJyQ14bJOk0I2X6I/cf1lb6q9 /Nlq8QnwUyrjbp Date: Mon, 6 Dec 2010 17:54:53 +0100 Message-ID: <50B0A6B1-5025-4309-96D0-DE7245AA71A7@gmx.de> X-GeMail-Ref: From: manner.moe@gmx.de To: "Adrian Glaubitz" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-Mailer: GcMail 5.2.3.0(RG6) http://www.gcmail.de X-Y-GMX-Trusted: 0 X-Originating-IP: 213.165.64.22 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291654481-00000C0F-D00A74D0/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=NO_REAL_NAME,SPF_HELO_PASS, SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: manner.moe@gmx.de List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 16:54:42 -0000 >Betreff : Re: [linux-minidisc] another way to send SCSI commands >Gesendet: 06.12.2010 11:35:17 >An : "Michael Karcher " >Von: "Adrian Glaubitz " >----- Originale Nachricht ----- >On Dec 6, 2010, at 12:59 AM, Michael Karcher wrote: >> Am Montag, den 06.12.2010, 00:42 +0100 schrieb Adrian Glaubitz: >>> Without going yet into detail, two questions: >>> >>> - Is this source Windows-specific? ("- requires [...] win32err.h") >> That header is only required on Windows. It is included in dvd+rw-tools. >> >>> - What are the requirements to get the code compile? does >>> one simply need the headers? >> Right. >>> Or is it just transport.hxx which contains most of the code? >> Exactly this. Quoting myself: "The whole implementation is currently >> inside a header file, so you can't avoid to to have it linked into your >> program." >Then, why isn't it committed to the git tree yet? =) If the code works fine, >please don't hesitate to commit it and credit Thomas. >Adrian The rewritten test tool depends on a patched version of transport.hxx and may not work on himd devices with the original version. I think we should test it on all supported platforms first to make the patches and then commit it with the patches or with patched versions of needed header files. Thomas From Michael.Karcher@fu-berlin.de Mon Dec 06 18:02:12 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPeS3-0001oD-1f>; Mon, 06 Dec 2010 18:02:11 +0100 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PPeS2-00077X-Oe>; Mon, 06 Dec 2010 18:02:10 +0100 Received: from aquila.physik.fu-berlin.de ([160.45.35.69]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PPeS2-00011Q-JX>; Mon, 06 Dec 2010 18:02:10 +0100 From: Michael Karcher To: manner.moe@gmx.de In-Reply-To: <50B0A6B1-5025-4309-96D0-DE7245AA71A7@gmx.de> References: <50B0A6B1-5025-4309-96D0-DE7245AA71A7@gmx.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Dec 2010 18:03:04 +0100 Message-ID: <1291654984.6295.87.camel@aquila> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Originating-IP: 160.45.35.69 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291654931-00000C0F-617E9C60/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 17:02:12 -0000 Am Montag, den 06.12.2010, 17:54 +0100 schrieb manner.moe@gmx.de: > The rewritten test tool depends on a patched version of transport.hxx and may > not work on himd devices with the original version. > I think we should test it on all supported platforms first to make the > patches and then commit it with the patches or with patched versions of > needed header files. Did you make additional changes to transport.hxx to the ones I did? If yes, please send patches. Regards, Michael Karcher From adrian.glaubitz@googlemail.com Mon Dec 06 23:13:55 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPjJi-0003ZG-KA>; Mon, 06 Dec 2010 23:13:54 +0100 Received: from mail-ew0-f45.google.com ([209.85.215.45]) by relay1.zedat.fu-berlin.de (Exim 4.69) for linux-minidisc@lists.fu-berlin.de with esmtp (envelope-from ) id <1PPjJi-0001Ur-Hd>; Mon, 06 Dec 2010 23:13:54 +0100 Received: by ewy10 with SMTP id 10so7543929ewy.4 for ; Mon, 06 Dec 2010 14:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=bv4gEiEvjoCU8lou0NTrK3WimUpB3YYajg2ua+1/AL0=; b=s3WgLw/m/YYufVZxLfIb4+CvLAPh+2fig9x488EalMDf8fpahSMSwATi/V+FyVj4lA /9bGye2Oup84dco6bMDNSPGP3ylo9xFBbK1U9eh4PpVC03FXPufdvOTsG1ljOBZVGXxG qX5bhYZD2N7fDc4Z+tbfXPXijCUlCJXSHhsjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uSAclBWXMq5uJI+Nh3tRKo04rHSqGx9Wp7Y9CngGvsT3CTLQtNdCgHH98rA1x242du tntm9btjFSHbDak2HslRDFgsMvjYN6YS4Hs2J81Nq0GfPpJKedvbeMFwuMEJad936TcC JH1VBPAzWh58BeXDu3UzlsH6YlVPkpCWOYCZ0= Received: by 10.213.15.203 with SMTP id l11mr27277eba.73.1291673634241; Mon, 06 Dec 2010 14:13:54 -0800 (PST) Received: from kri3-1x-dhcp348.studby.uio.no (kri3-1x-dhcp348.studby.uio.no [193.157.241.96]) by mx.google.com with ESMTPS id t5sm3334315eeh.2.2010.12.06.14.13.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 14:13:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Adrian Glaubitz In-Reply-To: <50B0A6B1-5025-4309-96D0-DE7245AA71A7@gmx.de> Date: Mon, 6 Dec 2010 23:13:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5143C4AC-3DB6-454B-B911-93ED0638B906@googlemail.com> References: <50B0A6B1-5025-4309-96D0-DE7245AA71A7@gmx.de> To: manner.moe@gmx.de X-Mailer: Apple Mail (2.1082) X-Originating-IP: 209.85.215.45 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1291673634-00000C0F-73FC40CE/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Algerien.ZEDAT.-Berlin.DE X-Spam-Level: x X-Spam-Status: No, score=1.8 required=5.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS Cc: linux-minidisc@lists.fu-berlin.de Subject: Re: [linux-minidisc] another way to send SCSI commands X-BeenThere: linux-minidisc@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Mailing list for the linux-minidisc project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 22:13:55 -0000 On Dec 6, 2010, at 5:54 PM, manner.moe@gmx.de wrote: >=20 > The rewritten test tool depends on a patched version of transport.hxx = and may=20 > not work on himd devices with the original version. > I think we should test it on all supported platforms first to make the=20= > patches and then commit it with the patches or with patched versions = of=20 > needed header files.=20 Well, it actually doesn't compile on MacOS with the original headers (transport.hxx and asctable.h), while it does without any problems on Linux. I didn't have the opportunity to test whether the compiled version actually works, don't have my HiMD Walkman currently around. If you had to make any changes to the headers, please provide the = patches as well, as Michael already stated. I wanted to commit the new version of himdscsitest together with the necessary headers so I can actually include the utility in our = Debian/Ubuntu packages. Since it's very easy to compile the dvd+rw-tools version of himdscsitest on Linux, we have a quick and dirty preliminary command line utility to send SCSI commands to the HiMD devices before = QHiMDTransfer will actually incorporate the functionality. Adrian=