> Existing bus abstractions tend to let think that the same software driver
> can deal with different buses, bridges or IO methods without having to
> care about how these things actually behave, notably regarding buffering
> and ordering rules. This is untrue.
A good bus abstraction lets you care as much or as little as necessary.
The NetBSD framework (which we use) allows you to do this.
> Existing bus abstractions may let driver writer think that everything that
> addresses bridges, bus specific and arch specific properties is handled
> transparently given that the right abstract method is called in the right
> place. This is untrue.
This is called "a naive driver author", and it doesn't matter how good or
bad the bus abstraction is; these people can write BASIC in any language.
> Existing bus transactions may let think that driver writers donnot have
> to care with ordering rules and coherency issues between transactions in
> both directions targetting device and memory.
> This is untrue.
See above.
> I donnot know how the right bus generic abstraction could be, but for
> now, all those I saw donnot look statisfying to me, and it seems to me
> that they may lead to having numerous quite aesthetic drivers that are
> just broken due to driver (writer?) relying too much on some supposed
> generic cleverness of the bus abstraction that does not happen.
See above.
> When some weak memory ordering is involved, the only way to make things
> right and not too sub-optimal is to insert explicit barriers in the driver
> code. Flushing everything after the IO from the 'bus write/read'
> abstraction is broken.
Nobody that I'm aware of does anything this stupid. We certainly expect
the driver author to care about macro-ordering of bus operations.
> For example, if I want a WRITE TO MEMORY followed by a WRITE TO AN IO
> REGISTER performed from the C code to be seen consistently from the device
> (bus), most IO abstractions I have seen will do the bad work by just
> performing a memory barrier (or some additionnal barrier) after the WRITE
> TO THE IO REGISTER. If driver writer is not aware of this kind of
> subtleties, very ennoying bugs will be generated all around, in my
> opinion.
Very few architectures even support I/O registers, and the only one that
most people care about already guarantees write ordering in hardware.
The example you're positing is basically a non-issue, with the exception
of operation re-ordering by the compiler (and for this see above).
--
\\ 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
