* On Sat, 14 Oct 2006, Rolf Kalbermatter wrote:
The IO sys driver I have worked with and made myself in the past did use a number of specific kernel functions such as
NTKERNELAPI void Ke386SetIoAccessMap(int, IOPM *); NTKERNELAPI void Ke386QueryIoAccessMap(int, IOPM *); NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS, int); NTKERNELAPI NTSTATUS PsLookupProcessByProcessId(IN ULONG ulProcId, OUT PEPROCESS * pEProcess);
which all were and maybe still are considered undocumented. These are for manipulating the IO permission map so that applications can directly use the inp and outp opcode in application space for enabled IO adresses.
These are fns "doable" in a pretty strightforward way, IMHO.
Alternatively it can access IO ports through a kernel driver call using a combination of:
HalTranslateBusAddress MmMapIoSpace
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.
And the last one is "undoable" without some bigger emulation, I guess. Luckily we have only bugreports about a need of some old-fashioned port I/O... ;)
Especially the first method while being a bit faster for standard IO access is probably a real trouble to implement. I have not found a way to manipulate the Linux IO permission map without a specific kernel extension and don't think such an extension would ever make it in the mainstream kernel.
Yes for the last statement, but extraordinary user's mileage may vary. It can choose between (a) running wine as root and (b) running LIDS-patched kernel [8] plus this command:
# lidsadm -A -s /path/to/some_wine_binary_piece -o CAP_SYS_RAWIO -j GRANT
Right? Then it would be nice to get this "some_wine_binary_piece" as a separate executable file. Well, maybe I should have gone asleep instead of writing this ;)