Re: Wine device drivers proposal
--- Evgeny F [EMAIL PROTECTED] wrote:
Damjan Jovanovic [EMAIL PROTECTED] wrote:
What microdriver are you talking about? Are you
working on STI? For STI, there is a convention for
Windows 2000 and onwards, something like
\\.\USBSCAN\... (check the STI documentation on
MSDN).
If it's STI, I have some code; do you want it?
Yes, it is scanner microdriver.
Yes, boundaries absolutely must be preserved,
because
USB bulk reads and writes occur in packets, not as
streams. How are you going to extract packets from
a
stream at the other end?
There are some new type of socket, present since
2.6.4 kernel described
in unix(7) manual page - SOC_SEQPACKET, which is
both
connection-oriented and preserves message
bounderies. Will it work for
that purpose
No. Here's why:
Your microdriver has a socket, and wine has a socket
connected to that socket. When wine writes, your
microdriver gets packets, and your microdriver can
extract the boundaries and use the packets. But what
happens when wine wants to read from the socket? How
do you know to read from the scanner and send wine the
packet, and what size that packet should be? You
don't. Reading a USB pipe is a synchronous pull
protocol and sockets use an asynchronous push
protocol. That is why sockets can't be used.
I've given this some thought, and wine needs to be
changed. Drastically. Look at the hacks in
ntdll/cdrom.c, kernel/volume.c and many others - the
current handle system is coming apart at the seams. My
advice is to add handle types eg. a file handle,
cdrom handle, device handle, ..., with each handle
being a pointer to something like:
struct Handle {
DWORD (*ReadFile)(VOID *buffer, DWORD size);
DWORD (*WriteFile)(VOID *buffer, DWORD size);
DWORD (*DeviceIoControl)(VOID *buffer, DWORD
size);
...
};
and have the ReadFile(), WriteFile() and
DeviceIoControl() simply call the function pointers in
the handle. That way it would be trivial to add a new
device driver type of thing into wine: write new
functions, and change CreateFile() to initialize
handles for that device type with the right
combination of function pointers.
What do you think?
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: Wine device drivers proposal
Damjan Jovanovic [EMAIL PROTECTED] wrote: What microdriver are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it? Yes, it is scanner microdriver. Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end? There are some new type of socket, present since 2.6.4 kernel described in unix(7) manual page - SOC_SEQPACKET, which is both connection-oriented and preserves message bounderies. Will it work for that purpose
Re: Wine device drivers proposal
Damjan Jovanovic [EMAIL PROTECTED] wrote: What microdriver are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it? Yes, it is scanner microdriver. Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end? There are some new type of socket, present since 2.6.4 kernel described in unix(7) manual page - SOC_SEQPACKET, which is both connection-oriented and preserves message bounderies. Will it work for that purpose?
Re: Re[4]: Wine device drivers proposal
--- Vitaliy Margolen [EMAIL PROTECTED] wrote: Monday, August 29, 2005, 3:13:43 AM, Damjan Jovanovic wrote: It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine). So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete. How exactly did you change DeviceIoControl()? Mm that's a bit more complicated then just DeviceIoControl. Actually believe it or not but DeviceIoControl is unchanged. What did you change? NtDeviceIoControl()? Vitaliy __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Wine device drivers proposal
--- Evgeny F [EMAIL PROTECTED] wrote: In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: 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() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices (\\.\)? I don't know for sure, but I think there is no convention. The device names are dependant on the hardware / system. What microdriver are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it? 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. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end? This is, by the way, a serious problem. I still haven't figured out how to do it, without major major changes to NTDLL, wineserver, and several other parts of wine. There are (ugly) hacks, like messing with the DLL import table to dynamically link it to other implementations of ReadFile(), WriteFile() and such. Bye Damjan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Re[2]: Wine device drivers proposal
--- Vitaliy Margolen [EMAIL PROTECTED] wrote: Saturday, August 27, 2005, 6:24:21 AM, Evgeny F wrote: In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: 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() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices (\\.\)? [skip] It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine). So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete. How exactly did you change DeviceIoControl()? I would suggest to cooperate in this development effort. There are number of issues to resolve, that a not so trivial. Also there are limits to how far wine can go in emulating native kernel. Some things are gust impossible to implement in the same manner. Please join #winehackers channel on freenode.net to discuss the the subject. Vitaliy. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re[4]: Wine device drivers proposal
Monday, August 29, 2005, 3:13:43 AM, Damjan Jovanovic wrote: It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine). So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete. How exactly did you change DeviceIoControl()? Mm that's a bit more complicated then just DeviceIoControl. Actually believe it or not but DeviceIoControl is unchanged. Vitaliy
Re: Wine device drivers proposal
In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: 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() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices (\\.\)? 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. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny
Re[2]: Wine device drivers proposal
Saturday, August 27, 2005, 6:24:21 AM, Evgeny F wrote: In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: 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() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices (\\.\)? [skip] It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine). So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete. I would suggest to cooperate in this development effort. There are number of issues to resolve, that a not so trivial. Also there are limits to how far wine can go in emulating native kernel. Some things are gust impossible to implement in the same manner. Please join #winehackers channel on freenode.net to discuss the the subject. Vitaliy.
Re: Wine device drivers proposal
Hi, On Mon, Apr 04, 2005 at 08:58:32AM +1000, Troy Rollo wrote: Of course such a mechanism would be much slower than a native driver, and may run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel currently provides no interface to say switch to this task now - the scheduler code simply does not provide for it (which is a shame, because a directed yield call with an associated call to return the remainder of the donated time slice(*) to the donor would be a simple way of radically improving the performance of anything that uses wineserver). AFAIR (some recent discussion?) there were good reasons for not implementing that, since it isn't all that helpful. But I'm not sure... So, input an output instructions: possible but likely to be slow, sometimes unacceptably slow. Interrupts are more of a problem due to the inability to do a directed yield. If you seriously want to attempt this, I would suggest your first port of call would be to the kernel list to discuss the possibility of implementing directed yield. Nope, that should probably be the Con Kolivas list, since they do a LOT more about scheduling things. An interesting experiment could be using a recent Con Kolivas kernel (2.6.11-ck3) and installing schedtoold and let wineserver run in isochronous scheduling (SCHED_ISO). Then try some nice games to see what happens... Andreas Mohr
Re: Wine device drivers proposal
Hi, On Sun, Apr 03, 2005 at 08:20:48PM -0400, C. Scott Ananian wrote: On Mon, 4 Apr 2005, Troy Rollo wrote: run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel currently provides no interface to say switch to this task now - the scheduler code simply does not provide for it (which is a shame, because a directed yield call with an associated call to return the remainder of the donated time slice(*) to the donor would be a simple way of radically improving the performance of anything that uses wineserver). Um, I'm fairly certain that rendezvous via any kernel synchronization mechanism (semaphores, condition variables, etc) will do exactly what you want. The blocked task goes to sleep and the rest of the time slice is preferentially transfered to the newly-active task. Such a mechanism is much more general than your proposed special interface, and accomplishes the same end. Ah, right, THAT one was the main reason a direct yield is not implemented. The usual blocking architecture achieves the same thing. Andreas Mohr
Re: Wine device drivers proposal
--- James Courtier-Dutton [EMAIL PROTECTED] 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
Re: Wine device drivers proposal
--- Kuba Ober [EMAIL PROTECTED] 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. 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 I agree, Kuba. Which of the approaches I suggested (or any new ones) do you propose? Bye Damjan __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Re: Wine device drivers proposal
On Mon, 4 Apr 2005 10:20, C. Scott Ananian wrote: Um, I'm fairly certain that rendezvous via any kernel synchronization mechanism (semaphores, condition variables, etc) will do exactly what you want. The blocked task goes to sleep and the rest of the time slice is preferentially transfered to the newly-active task. I'm not sure where you got that from, but would appreciate any references. I know that a casual reading of some manual pages might suggest this, but that does not necessarily reflect the real in-kernel behaviour. The manual pages may mislead because it is not necessarily obvious to somebody who has not worked at the kernel level (or had the benefit of John Lyons' lecturing) that there is a difference between a process being runnable (ready to run or awake), and a process being in the running state (actually executing on a CPU). It also doesn't help that the ps command uses R for runnable and has no separate state indicator for running. The historical (UNIX) behaviour has always been that any processes waiting on the event merely gets woken when the event arrives, but that will only affect *whether* the process is considered for running, not *when*. The when part is normally when the scheduler is good and ready to run it. If it were any different, a pair of conspiring threads would be able to starve the rest of the system (the directed yield/return to donor mechanism does not do that as the donee only gets time up until the original thread would have lost its time slice anyway). I have not seen anywhere in the Linux kernel that behaves differently to this, and I can see nothing in the scheduler that causes or enables a determinative and immediate transfer of control to a particular thread. On Mon, 4 Apr 2005 17:53, Andreas Mohr wrote: AFAIR (some recent discussion?) there were good reasons for not implementing that, since it isn't all that helpful. But I'm not sure... A reference to the discussion would be helpful - I can't find it by searching the ck list archive. On Mon, 4 Apr 2005 17:55, Andreas Mohr wrote: the main reason a direct yield is not implemented [is that] The usual blocking architecture achieves the same thing. I think perhaps we are talking at cross purposes. In directed yield, the donor thread, which has access to the CPU until such time as it either yields or is pre-empted, donates that access directly to the donee thread. The donee thread immediately gets access to the CPU, and can return the CPU to the donor thread if it completes its task before the original thread would have been pre-empted. Ideally the time is charged to the donor rather than the donee. As far as I can see, there is nothing in the 2.6 scheduler that does that.
Re: Wine device drivers proposal
On Sat, 2 Apr 2005 08:15, Kuba Ober wrote: Not really. It just needs some sort of device-class-specific forwarding protocol. usbfs and libusb already do that, and you should be able to run any windows driver that way without even touching the kernel. USB (along with SCSI) is a special case that because of its architecture can participate in such a forwarding arrangement for devices other than the hub or host controller device. Most other device drivers (and when I say device driver I mean the thing that drives the hardware) involve direct use of the input and output instructions of the CPU, and interrupts. Now, you *could* trap the input and output instructions and emulate them via a kernel module, likely one involving entries in /proc to provide an interface for granting access to particular I/O ports and a file that could be used to access each device for which ports were made available. Of course such a mechanism would be much slower than a native driver, and may run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel currently provides no interface to say switch to this task now - the scheduler code simply does not provide for it (which is a shame, because a directed yield call with an associated call to return the remainder of the donated time slice(*) to the donor would be a simple way of radically improving the performance of anything that uses wineserver). So, input an output instructions: possible but likely to be slow, sometimes unacceptably slow. Interrupts are more of a problem due to the inability to do a directed yield. If you seriously want to attempt this, I would suggest your first port of call would be to the kernel list to discuss the possibility of implementing directed yield. * - a directed yield call would allow the current thread to donate the remainder of its current time slice to another thread. The context switch occurs immediately. For maximum value, such a call effectively requires a companion call that allows that other thread to return any of the time slice it does not need to the donor, without necessarily knowing who the donor was.
Re: Wine device drivers proposal
On Mon, 4 Apr 2005, Troy Rollo wrote: run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel currently provides no interface to say switch to this task now - the scheduler code simply does not provide for it (which is a shame, because a directed yield call with an associated call to return the remainder of the donated time slice(*) to the donor would be a simple way of radically improving the performance of anything that uses wineserver). Um, I'm fairly certain that rendezvous via any kernel synchronization mechanism (semaphores, condition variables, etc) will do exactly what you want. The blocked task goes to sleep and the rest of the time slice is preferentially transfered to the newly-active task. Such a mechanism is much more general than your proposed special interface, and accomplishes the same end. --scott JMBLUG SARANAC MI6 mustard KUBARK quiche ammunition TASS ODEARL Mossad nuclear security SEQUIN KUHOOK Moscow shotgun TPAJAX jihad NRA Suharto ( http://cscott.net/ )
Re: Wine device drivers proposal
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
Re: Wine device drivers proposal
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
Re: Wine device drivers proposal
I am not trying to _load_ a Windows driver (that either requires kernel support for the Windows DDK, like ndiswrapper has, or emulation of an entire x86, like bochs does). Not really. It just needs some sort of device-class-specific forwarding protocol. usbfs and libusb already do that, and you should be able to run any windows driver that way without even touching the kernel. ndiswrapper does what it does because they want to expose non-usb devices and to the whole linux system at that. I.e. they support pci devices as well as usb. If they wanted to support usb only, it's all plain userspace. You can emulate network adapters in userspace using TAP or however it's called, and you can talk to arbitrary usb devices from userspace via usbfs and libusb. In fact, for a wide variety of PCI drivers out there it should be perfectly feasible to provide a short-circuit kernel driver that could expose full access to a PCI device do a userland application, thus allowing wine to support arbitrary PCI devices as well. Considering that 2.6 kernel already has hardware abstraction that disconnects actual hardware accesses (like port/read writes and so on) from the logic of the PCI device drivers, it wouldn't be that hard to make such a gizmo. http://vtun.sourceforge.net/tun/faq.html http://libusb.sourceforge.net/ Cheers, Kuba
Re: Wine device drivers proposal
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
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/
Re: Wine device drivers proposal
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
Re: Wine device drivers proposal
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 pgp36ahV8gAZ0.pgp Description: PGP signature
Re: Wine device drivers proposal
--- Mike McCormack [EMAIL PROTECTED] 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. I am not trying to _load_ a Windows driver (that either requires kernel support for the Windows DDK, like ndiswrapper has, or emulation of an entire x86, like bochs does). What I am trying to do is _replace_ a Windows driver with equivalent libusb functionality, getting, in effect, something like this: Application (eg. the Gimp) | v special SANE backend | v SANE to TWAIN converter | v Windows user-space TWAIN driver (by manufacturer) | v STI | v Wine (with drivers) | v Wine (user-space) driver | v libusb | v kernel Mike Damjan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
