FW: XFree86 Port (Message from XFree86/OS2 developer)

["Suhaib M. Siddiqi" <Ssiddiqi@InspirePharm.Com>]

This is for users, may be you will find it informative.
Xterm, xdm etc are the issue because Cygwin support TTY.

After spending a couple hours on Internet I found 3 freeware drivers
for Windows which do I/O, and memory maping what he is describing in his
message
as a must for XFree86 server to run.

Suhaib

>
> Hi,
> Compiling the stuff with Cygnus GNU or even better with EMX and RSX, is
> as you correctly found out, not the real problem with the port.
> XF86SUP.SYS is the essential part of the port. This is not only the
> mentioned fastio and pmap devices, but also (for xconsole and xterm) a
> rather complete Unix TTY/PTY/Console emulation. If you neglect xterm,
> xdm and xconsole for a while, infact your showstoppers are fastio and
> pmap.
> To explain what they do:
> pmap allows to map arbitrary physical memory into the X server's address
> space. I don't know cygwin enough to know whether there is a working
> mmap/munmap Unix call available, if so, it must be capable of accessing
> and mapping not only files and virtual memory pages into memory, but also
> physical memory. I doubt that this will work without the help of a device
> driver in NT, because the ability to access - even read/write - arbitrary
> memory from a user process in NT is the worst security leak ever
> possible -
> even with OS/2 and a lack of security protection this is
> impossible without
> driver assistance.
> fastio is a real hack. As you might have found out, there are several
> inline assembler portions in the server code which directly access I/O
> ports. If you go through a (possible in theory) kernel mechanism
> to emulate
> I/O accesses - the EMX library provides such a method in OS/2 - then you
> will slow down these critical parts of the code (that's why they are
> assembler!) by one or two orders of magnitude. The Unix ports
> have the same
> problem, and the trick I built into fastio is comparable to the way it was
> solved in Unix. The processor has two bits IOPL in its EFLAGS CPU
> register,
> which control a fence of privilege below which I/O accesses and some other
> instructions in user mode won't trap. OS/2 by default sets this
> to 2, meaning
> the user processes running in ring 3, won't be allowed to do I/O. fastio
> is a small ring 0 code (which is capable to alter these bits - user code
> can't) which is called at task time by the X server to modify its own
> per-process copy of the EFLAGS register. This should also be possible
> for NT, with the help of a small driver.
>
> Hope this helps, if not feel free to ask again
> Holger
>
> --
> Signature fault - code dumbed
>