On 19-Oct-00, 13:28:02 Eric Lowe wrote:
>  Hello,

Hi!

> > Currently, bus_space_read/write_n() functions do implicit memory
> > barrier. Existing drivers rely on this. According to bus_space(9),
> > it is incorrect.
> > 
> > All other read/write functions are affected as well.

>  IMO this is _broken_.  Implicit barriers in macros are inefficient
>  and only contribute to hidden bugs.

I think we should stop abusing "implicit" word. It will be explicitly
stated in manual that bus reads and writes are executed in order.

It is sometimes just convenient for programmer to have barriers between
each read and write to bus. Yes, it is inefficient, but in places that
need that, one can use no-barrier versions.

It's not that important whether to have bus_space_read_1() and
bus_space_read_nobarrier_1() or to have bus_space_read_barrier_1()
(perhaps named bus_space_read_ordered_1()?) and bus_space_read_1() -
the second just won't force to change all drivers.


>  I pointed out a bug to 
>  a fellow engineer here who had no idea that barriers were
>  things that were needed in a driver.  It was a case of "this should
>  work like this but the real semantics are different".

Interface with implicit ordering will help him write correct driver.
When he would like to improve performance, he would have to learn about
barriers.


>  Such issues
>  are not only related to hardware, but to software synchronization
>  as well.  Better to wean them now then to have them writing
>  dangerous code later..

From pedagogical point of view.. perhaps

But after reading bus_space(9) they should be aware of barriers anyway.


[ .. MP problem example .. ]

>  So I think the _right_ way should
>  be taught, instead.

There are two kinds of people:

- people who know what barrier is - this group needs simple,
convienient interface that allows optimization too

- people who don't know what barrier is - if it is possible
to make them write _working_ drivers - it's great

(yes.. I know that there is a third kind as well, but...)



>  I suggest setting an ultimatum.  And document it well.
>  "This will be broken in version xxx.  Until then,
>  if you want to be safe, use the new function call".

It may be avoided.


>  Please don't clobber the code with #ifdef THIS_BROKEN_INTERFACE
>  etc.  It's messy.  The old Linux way of fixing this was to
>  make you #define _USE_SUCHANDSUCH_BROKEN_INTERFACE to access
>  the calls.  Rather, make the common case issue the implicit
>  barrier, and leave bus_space_barrier() functions in for now.
>  Then, make the common case more efficient later.

Clobbering code (drivers) with #ifdef THIS_BROKEN_INTERFACE wasn't even
considered. Adding one #define *IMPLIED_BARRIERS at the top of some
drivers was (and is).

Making common case efficient _requires_ human made changes to each
driver.




        Witold J. Wnuk