Re: [Hpoj-devel] Problem at compile time

[Burkhard K. <bu...@bu...>]

PASCHAL,DAVID (HP-Roseville,ex1)
> > You're right David, I've hacked for a few hours since my last 
> > messages, 
> > and I've found that (apparently) the function start_bh_atomic and 
> > end_bh_atomic don't exist any more since 2.3.43.
> > So I just commented out these functions, and it compiled.
> > I can insmod the modules, and run hpo devid without errors.
> 
> Hi, Damcha.  I'm glad you got it working, but I would be a little concerned
> about just removing these calls altogether as opposed to trying to find out
> if there's a proper replacement in the newer kernels.

From looking at newer 2.4.0-test kernels I noticed that all references
to start_bh_atomic and end_bh_atomic have been removed. 
Both functions where inlines with start_bh_atomic calling 
synchronize_irq() which is a #define to barrier() in <asm/softirq.h> which 
in turn is a #define barrier() __asm__ __volatile__("": : :"memory")
in <linux/kernel.h>. 

It seems that bottom halves synchronisation in 2.4.0 now is resolved
in some automatted way.

Maybe both functions should be renamed and defined in "ieee12844.h" 
somehow like:

static void inline x_start_bh_atomic() {
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,xxx)
#define x_start_bh_atomic()	
else
#define x_start_bh_atomic()	start_bh_atomic()
#endif
}

Inclusion of start_bh_atomic and end_bh_atomic headers in ieee12844.c
and ieee12844pp.c is not done directly from <asm/softirq.h> thus 
no particular treatment should be necessary.

BTW: I am not familiar with socket programming, why is/was
it necessary to explicitly synchronize bottom_halves? I would have
expected (maybe naively) that this issue gets handled by lower
layers. The parport driver does not use bh handlers.


Burkhard
-- 
Burkhard Kohl			buk at/auf buks.ipn.de