src-test2/sys/dev/io, branch release/10.0.0 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F10.0.0 2010-04-28T15:38:01Z - Extract the IODEV_PIO interface from ia64 and make it MI. 2010-04-28T15:38:01Z Attilio Rao attilio@FreeBSD.org 2010-04-28T15:38:01Z urn:sha1:d8b878873e7aa8df1972cc6a642804b17eb61087 In the end, it does help fixing /dev/io usage from multithreaded processes. - On i386 and amd64 the old behaviour is kept but multithreaded processes must use the new interface in order to work well. - Support for the other architectures is greatly improved, where necessary, by the necessity to define very small things now. Manpage update will happen shortly. Sponsored by: Sandvine Incorporated PR: threads/116181 Reviewed by: emaste, marcel MFC after: 3 weeks Use io(4) for I/O port access on ia64, rather than through sysarch(2). 2010-01-11T18:10:13Z Marcel Moolenaar marcel@FreeBSD.org 2010-01-11T18:10:13Z urn:sha1:409a390c3341fb4f162cd7de1fd595a323ebbfd8 I/O port access is implemented on Itanium by reading and writing to a special region in memory. To hide details and avoid misaligned memory accesses, a process did I/O port reads and writes by making a MD system call. There's one fatal problem with this approach: unprivileged access was not being prevented. /dev/io serves that purpose on amd64/i386, so employ it on ia64 as well. Use an ioctl for doing the actual I/O and remove the sysarch(2) interface. Backward compatibility is not being considered. The sysarch(2) approach was added to support X11, but support for FreeBSD/ia64 was never fully implemented in X11. Thus, nothing gets broken that didn't need more work to begin with. MFC after: 1 week Remove D_NEEDGIANT from io(4). 2008-08-08T13:43:56Z Ed Schouten ed@FreeBSD.org 2008-08-08T13:43:56Z urn:sha1:cacdd70cc751fb68dec4b86c5e5b8c969b6e26ef There is no need to mark this device node to use Giant. The only architectures that use io(4) (i386 and amd64) only change a flag in td->td_frame, which is only accessed by curthread. Apart from this change, I think some fishy things may happen when using /dev/io in multithreaded applications. I haven't tested, but looking at the code, the flag doesn't get cleared when close() is called from another thread, but this may not be this important. I'm not removing D_NEEDGIANT from mem(4), because this driver isn't Giant safe at all (it calls GIANT_REQUIRED). Remove the unused major/minor numbers from iodev and memdev. 2008-06-25T07:45:31Z Ed Schouten ed@FreeBSD.org 2008-06-25T07:45:31Z urn:sha1:721351876cd4d3a8a700f62d2061331fa951a488 Now that st_rdev is being automatically generated by the kernel, there is no need to define static major/minor numbers for the iodev and memdev. We still need the minor numbers for the memdev, however, to distinguish between /dev/mem and /dev/kmem. Approved by: philip (mentor) Add module versions. 2004-08-02T20:42:28Z Mark Murray markm@FreeBSD.org 2004-08-02T20:42:28Z urn:sha1:ce46e2059e16557a44be599f86de42c0e1a13220 Break out the MI part of the /dev/[k]mem and /dev/io drivers into 2004-08-01T11:40:54Z Mark Murray markm@FreeBSD.org 2004-08-01T11:40:54Z urn:sha1:8ab2f5ecc596131f6ca790d6ae35540c06ed7985 their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.