direct access to IO space [Was: kernel level drivers - next try]
James at superbug.co.uk
Mon Oct 16 15:55:03 CDT 2006
Saulius Krasuckas wrote:
> * On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
>> * Rolf Kalbermatter wrote:
>>> * Saulius Krasuckas [saulius2 at ar.fi.lt] wrote:
>>>> Today I have tried to compile ntoskrnl.exe, then checked out master
>>>> branch, compiled stock Wine, then tried to run win32 app which do
>>>> simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply
>>>> loaded, did its initialization and immediatelly exited.
>>> I'm not positive these can all be easily added to a process operating
>>> in user space without some specific kernel support for this
>>> functionality and in fact allowing full IO access to a user space
>>> application such as Wine just doesn't seem safe to me.
>> Why do we need to give an application direct access to IO space?
> Imagine some new motherboard model with uniq internal debugging device.
> And its supporting software designed only for Win32 platforms. Or imagine
> some proprietary portable music player connected via LPT and using its own
> protocol. User wants to make them work on linux. Just that's why.
> I see two reports in out bugzilla on this topic: , .
> IMHO, we don't need to give this access to all of applications. We just
> need a way to redirect operation from a particular win32 app to small
> piece of "raw-io-unrestricted" code.
>  http://bugs.winehq.org/show_bug.cgi?id=3358#c6
>  http://bugs.winehq.org/show_bug.cgi?id=3836#c8
This feature is being ask for by people who don't understand what most
hardware requires from a "driver".
1) IO ports or memory mapped IO.
2) DMA handler
3) IRQ handler
Getting IO port access in wine really is not going to help a whole lot!
More information about the wine-devel