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

[Marcus Meissner]

On Mon, Oct 16, 2006 at 11:45:01PM +0300, 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.

We have this already to some degree, see dlls/winedos/ioports.c.

Ciao, Marcus