Date: Mon, 23 Oct 2000 17:40:56 -0700 From: Mike Smith <msmith@freebsd.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> 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: <200010240041.e9O0euh05542@mass.osd.bsdi.com> In-Reply-To: Your message of "Thu, 19 Oct 2000 20:41:45 %2B0200." <Pine.LNX.4.10.10010192000010.2281-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> From the point of view of multiple platform architectures, are the se=
mantics
>>> of these guaranteed to include synchronization wrt I/O devices?
>> =
>> These are semantically equivalent to the bus_space_barrier() operation=
s =
>> applied to a bus space that represents system memory.
>> =
>> ie. no, they don't. You should use bus_space_barrier() against the bu=
s =
>> space(s) your peripheral occupies. (Yeah, this is a bit of overkill..=
=2E)
> =
> 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 t=
hat
> 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. ;-)
This is semantically correct. 8)
> 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 stup=
id
> or sub-optimal device drivers.
I'm not sure I parse that, but I probably agree. 8)
> 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 guarantee=
d
> 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.
The more I look at things, the more I agree with you here. Fortunately, =
many peripheral designers are learning to implement more efficient =
interfaces, so the need for barriers is slowly being reduced.
-- =
=2E.. 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?200010240041.e9O0euh05542>