SCSITaskDevice vs our own driver
Hi, Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The way I see it, there are two ways to do this: 1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like. Pros: No kernel code. Somewhat familiar paradigm to Windows programmers. Cons: Complicated usage. Needs every handle to device files closed. 2. Write an I/O Kit driver that exports the functionality we want. This way, we can get whatever we want that isn't exported to userspace by the current drivers. We could add this funcionality as a set of system IOCTLs. Pros: Familiar paradigm to UNIX programmers. Fits in with the current FD-based code. We can implement other stuff, too (like drive locking). Cons: Kernel mode C++. Need I say more? So each method has its pros and cons. I'd like to hear which one you guys prefer. If you don't know, that's OK. I personally don't like either of them, so if you have an alternative, I'll be glad to hear it... unless I have to tear it down as unfeasible. My current patch does it the first way (except for closing the server-side FD, which isn't implemented), but I'd really like some input before I proceed with it. Thanks. Chip
On Oct 16, 2009, at 6:01 PM, Charles Davis wrote:
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like.
I don't believe that's correct: http://developer.apple.com/mac/library/qa/qa2001/qa1179.html Mac OS X specifically does not support SCSI pass-through for storage devices. -Ken
Charles Davis <cdavis(a)mymail.mines.edu> writes:
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like.
I don't think we can realistically require the device to be unmounted. Most apps will want to check for files too. -- Alexandre Julliard julliard(a)winehq.org
On Sat, Oct 17, 2009 at 12:39 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like.
I don't think we can realistically require the device to be unmounted. Most apps will want to check for files too.
If that only leaves option 2. which would require the C++ driver, can or should it be hosted on winehq in another git tree? I am sure you would not want to keep it in the main wine tree but if it was hosted somewhere else on Winehq then we could package it with the Wine bundle. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
On Sat, Oct 17, 2009 at 12:39 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like. I don't think we can realistically require the device to be unmounted. Most apps will want to check for files too.
If that only leaves option 2. which would require the C++ driver, can or should it be hosted on winehq in another git tree? I am sure you would not want to keep it in the main wine tree but if it was hosted somewhere else on Winehq then we could package it with the Wine bundle.
If I recall AJ's policy on choice of language, I'd think it would probably end up in a separate tree, probably somewhere on WineHQ.
Steven Edwards <winehacker(a)gmail.com> writes:
On Sat, Oct 17, 2009 at 12:39 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like.
I don't think we can realistically require the device to be unmounted. Most apps will want to check for files too.
If that only leaves option 2. which would require the C++ driver, can or should it be hosted on winehq in another git tree? I am sure you would not want to keep it in the main wine tree but if it was hosted somewhere else on Winehq then we could package it with the Wine bundle.
I don't think it should even be Wine-specific, it should be a generic solution that others can use too. Just create a project on SourceForge. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Charles Davis <cdavis(a)mymail.mines.edu> writes:
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like.
I don't think we can realistically require the device to be unmounted. Most apps will want to check for files too.
Good point. Based on what Ken and you said, I think we'll have to write our own driver. But, it's kernel-mode C++. I'm not sure you'd be willing to accept that solution, either.
participants (4)
-
Alexandre Julliard -
Charles Davis -
Ken Thomases -
Steven Edwards