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

[Saulius Krasuckas]

* 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