>>>>> "hartvig" == Hartvig Ekner <firstname.lastname@example.org> writes:
hartvig> I can't see that they are using wbflush in any way. Grepping
hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
hartvig> is something only present on some dec platforms and then the
hartvig> au1000 stuff - which would mean that any driver directly
hartvig> calling __wbflush would be unable to compile/load on the
hartvig> majority of kernels. Or am I missing something? (I haven't
hartvig> been using modules under MIPS at all).
Yes, you missed the definition of mb() :p
quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
hartvig> In fact, I can't find a single file including wbflush.h
hartvig> except system.h, and it doesn't look like anybody else should
hartvig> directly be including the wbflush.h file, but only use the
hartvig> macros in system.h:
hartvig> #define wmb() fast_wmb()
hartvig> #define rmb() fast_rmb()
hartvig> #define mb() wbflush();
hartvig> #define iob() wbflush();
hartvig> (which are differently defined if there is no WB configured).
but WB is configured in :)
quintela$ grep WB arch/mips/defconfig-pb1*
Other thing is that this machine should be using wbflush at all, but
that is a different story. I agree with (/me looks in archive),
*your* patch removing wbflush for that boards. They are only doing
"sync" ond wbflush, and that is the thing that __sync() already does.
I.e. If I have to chooses wich patch to integrate, the one exporting
__wbflush(), or the one removing it altogether from pb1*, I will
choose removing it. It looks superflous.
Later, Juan "who don't have that processor, and handwaving is easy".
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy