direct access to IO space [Was: kernel level drivers - next try]
marcus at jet.franken.de
Mon Oct 16 23:22:36 CDT 2006
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: , .
> 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.
More information about the wine-devel