> Speaking about bus_space_*(): Does it make the thing follow the PCI
> ordering rules? Very probably not since it is impossible on some systems.
There's no attempt to do this, no. However, it's possible to implement
this if there's a need.
> Typically, a driver may want to order some operations and also not break
> post buffering each time a write is performed. It may for example want to
> order some operations, but not flush all writes immediately. I didn't see
> how to tell bus about that.
The bus_space_barrier() interface takes the bus tag and handle as
arguments, so the ordering operations can make decisions about how they
should behave based on what you're operating on.
> Hmmm... That's the point I disagree on, btw. Inserting implicit barriers
> in the back of drivers can only be either sub-optimal or sometime not
> match driver expectations about ordering. Bus interface should allow more
> flexibility to drivers regarding ordering, in my opinion.
I think Warner answered this, and he probably understood your point
better; at the moment, the driver is solely responsible for managing
ordering. None of our current busspace backends perform any sort of
ordering.
> By the way, as I wrote in my previous mail, I am unable to propose a
> better interface. I only wanted to point out that bus abstractions are far
> from being perfect. They make portability possible without too much code
> complexity, but when working on a driver, I think we must not forget the
> reality of what actually happens inside the machine.
Just so. The real joy, of course, comes when you're trying to make a
drive behave "correctly" on a wide range of different machines. 8)
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
