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
Couldn't you also unmap the I/O ports memory and catch segmentation faults referring to that area, then reroute them through some system service running as root? It's safer than running wine as root.
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 ;)