Date: Thu, 19 Oct 2000 20:41:45 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mike Smith <msmith@FreeBSD.org> Cc: mjacob@feral.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include bus_at386.h bus_pc98.h src/sys/ia64/include bus.h src/sys/alpha/include bus.h Message-ID: <Pine.LNX.4.10.10010192000010.2281-100000@linux.local> In-Reply-To: <200010182132.e9ILW0h00958@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Oct 2000, Mike Smith wrote: > >=20 > > From the point of view of multiple platform architectures, are the sema= ntics > > of these guaranteed to include synchronization wrt I/O devices? >=20 > These are semantically equivalent to the bus_space_barrier() operations= =20 > applied to a bus space that represents system memory. >=20 > ie. no, they don't. You should use bus_space_barrier() against the bus= =20 > space(s) your peripheral occupies. (Yeah, this is a bit of overkill...) I seem to understand that we have separate APIs for the the ordering of real memory R|W and IO/MMIO R|W, but we donnot have anything for the ordering of both at the same time. In result, for example, any driver that feeds a device queue in memory and then tells the device about the readyness of the IO using MMIO is probably semantically broken under FreeBSD. ;-) Overkill it is, in my opinion, to want 100% (or more ;-) ) portability when IO/MMIO is involved, unless we don't care about having either stupid or sub-optimal device drivers. Ordering we sometimes want in device drivers, that may not be common when only real memory is involved, could be, for example: 1) Prevent reordering of reads due to speculative execution. Ensuring a `jump' or some `call' is executed is generally enough. 2) Coalesce a set of sequential writes in a single transaction. When=20 this is possible some kind of write barrier could be the optimal=20 way. 3) Ensure a write to memory followed by a write to MMIO happens in=20 order. If you want to solve (3), for example, on Alpha, you must use mb(). wmb() = =20 will not work since it orders independently memory-like and non memory-like regions. I still think that having an API for partial barriers is very confusing and can lead to having broken driver code, since it cannot be guaranteed to behave identically on all platforms. Unless special need, device drivers should probably limit themselves to full memory barriers if developper wants full portability without #ifdef'ing platform type. G=E9rard. > > On Wed, 18 Oct 2000, John Baldwin wrote: > >=20 > > > jhb 2000/10/18 03:30:12 PDT > > >=20 > > > Modified files: > > > sys/i386/include bus_at386.h bus_pc98.h=20 > > > sys/ia64/include bus.h=20 > > > sys/alpha/include bus.h=20 > > > Log: > > > Add in a simple API for memory barriers to machine/bus.h: > > > - barrier_read() enforces a memory read barrier > > > - barrier_write() enforces a memory write barrier > > > - barrier_rw() enforces a memory read/write barrier > > > =20 > > > Revision Changes Path > > > 1.11 +24 -1 src/sys/i386/include/bus_at386.h > > > 1.12 +24 -1 src/sys/i386/include/bus_pc98.h > > > 1.2 +23 -1 src/sys/ia64/include/bus.h > > > 1.7 +13 -1 src/sys/alpha/include/bus.h > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 > --=20 > .. every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10010192000010.2281-100000>