direct access to IO space [Was: kernel level drivers - next try]
saulius2 at ar.fi.lt
Mon Oct 16 15:45:01 CDT 2006
* 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.
More information about the wine-devel