direct access to IO space [Was: kernel level drivers - next try]

[James Courtier-Dutton]

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: [6], [7].
> 
> 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.
> 
> 
> [6] http://bugs.winehq.org/show_bug.cgi?id=3358#c6
> [7] 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!

James