Wine device drivers proposal
Hi I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially. I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver. The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty. 1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun). 2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries. 3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though. 4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver. Let me know what you think. Bye Damjan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Damjan Jovanovic wrote:
I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.
Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges. Mike
On Mon, Mar 28, 2005 at 07:52:48PM +0900, Mike McCormack wrote:
Damjan Jovanovic wrote:
I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.
Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware.
The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface.
You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges.
Actually for still imaging devices the Linux side uses libgphoto2, which is in userspace and uses libusb to access the kernel. I would really suggest to implement STI on top of libgphoto2 and try loading kernel drivers later. Ciao, Marcus
I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.
Drivers belong in the kernel.
Not necessarily. In fact, only the part that directly touches the hardware really belongs there. There's nothing wrong with doing rest of the processing (i.e. the non time-critical parts) in the userspace. In fact, that likely makes the kernel a safer place.
If there's no Linux driver for a device, then Wine cannot support it.
That would be stupid.
In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware.
Huh? What about sane? It can e.g. use libusb quite nicely and *portably* to say access usb scanners. I.e. it flies on both windows *and* linux.
You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges.
You could, with help of a special kernel driver to forward the requests between hardware and userspace. libusb and usbfs do that already for usb, i.e. at the current point in time wine can be able to natively support any usb device minidriver that doesn't use a class driver. Class drivers can be easily developed by snatching code from linux kernel, as long as licenses are fine of course. All that without touching the kernel in any way. And I mean here full support for *any* usb device, rain or shine. Network adapters (visible in wine only, but so what?), scanners, cheap webcams whose manufacturers don't care enough to release the specs, and the list goes on. Cheers, Kuba
Le ven 01/04/2005 à 17:06, Kuba Ober a écrit : [snip]
All that without touching the kernel in any way. And I mean here full support for *any* usb device, rain or shine. Network adapters (visible in wine only, but so what?),
Does that mean we'd need a database of USB identifiers? For network adaptors visible in Wine only: Wine doesn't have a TCP/IP stack. Would that be needed to use such network adaptors? Vincent
Damjan Jovanovic wrote:
Hi
I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.
Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially.
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle()
The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty.
1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun).
2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries.
3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though.
4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver.
Let me know what you think.
Bye Damjan
I would like this but mainly for a different reason. I help reverse engineer hardware so that we can write linux drivers for it. This reverse engineering task would be easier if I could install the windows drivers on my linux box and run them, and then watch their activity with the hardware. For this to work, we would have to implement the HAL.DLL in wine, a small kernel module for it to communicate with and probably a few other bits. This would greatly help the hardware reverse engineering requirements in order to get hardware to interoperate with Linux. Currently, I have to installed special .DLLs on a windows box and perform the logging there. I would much prefer to do it all on Linux. The side effect of this would be that wine will support some hardware even before Linux gets support for it. This "kernel module" would only be run for the reverse engineering task, as it would most likely make the linux kernel very insecure. Any comments James
--- James Courtier-Dutton <James(a)superbug.demon.co.uk> wrote:
Damjan Jovanovic wrote:
Hi
I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.
Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially.
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle()
The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty.
1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun).
2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries.
3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though.
4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver.
Let me know what you think.
Bye Damjan
I would like this but mainly for a different reason. I help reverse engineer hardware so that we can write linux drivers for it. This reverse engineering task would be easier if I could install the windows drivers on my linux box and run them, and then watch their activity with the hardware. For this to work, we would have to implement the HAL.DLL in wine, a small kernel module for it to communicate with and probably a few other bits.
This would greatly help the hardware reverse engineering requirements in order to get hardware to interoperate with Linux. Currently, I have to installed special .DLLs on a windows box and perform the logging there. I would much prefer to do it all on Linux.
The side effect of this would be that wine will support some hardware even before Linux gets support for it.
This "kernel module" would only be run for the reverse engineering task, as it would most likely make the linux kernel very insecure.
Any comments
James
I am not 100% happy about using the Linux kernel. How would we deal with: -Portability: It works only on Linux, nowhere else -ioctl(): how does the DeviceIoControl() functions know whether it is safe to use the native ioctl() function with the same control codes or not? Bye Damjan __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest
participants (6)
-
Damjan Jovanovic -
James Courtier-Dutton -
Kuba Ober -
Marcus Meissner -
Mike McCormack -
Vincent Béron