Burkhard Kohl [mailto:bu...@bu...] wrote:
> I'll try to summarize the status of our attempts.
> Unfortunately I do not
> have a MP machine and thus can not test SMP issues directly.
>
> The 0.6 driver has problems related to SMP and 2.4.x issues because
> it uses non SMP-aware primitives for bottom half locking. Damcha and I
> replaced these with their SMP-aware counterparts (which just collapse
> to normal locking primitives for non-SMP systems - will say they work
> as well with non SMP systems).
Hi, Burkhard. Thanks for the update. It sounds like things are coming
along well.
> We have also addressed the issue of SMP-config awareness by consulting
> the <linux/autoconfig.h> header to decide upon the setting of the
> SMP-compiler flags for the hpoj driver modules. Without the patch
> the modules were compiled as non-SMP even if the kernel was configured
> for SMP.
I checked my RedHat 7 box (not yet recompiled or upgraded kernel), and it
has "autoconf.h", rather than "autoconfig.h".
> Now the modules will get compiled with SMP flags properly depending
> on the kernel SMP configuration. If someone wants to override
> this setting, he/she has to edit ieee12844/Makefile and uncomment
> one of the FORCE_SMP flag settings. (This might be helpful, if you
> don't have the kernel sources or use a precompiled kernel from a
> distribution package).
I think ieee12844.c requires the kernel sources, not just the files in
/usr/include/linux, to be able to pick up "net/sock.h". However, the
compile-time detection of SMP may be an issue if people legitimately compile
hpoj with SMP but boot with the "nosmp" parameter.
> I further adapted the ieee12844pp module to the new parport interface
> of 2.4.x kernels which should allow for "hotplugging" of parport
> devices. This feature is not well tested but should work ok with
> devices that are already visible when loading the ieee12844<pp>
> modules (the normal situation with board/card based parports).
How does parport detect and report "hotplugging"? I suspect it may be a lot
of trouble to make ieee12844*.c robust enough to make it tolerate
hot-plugging, particularly in the middle of a transfer. I found that even
with my changes from a few days ago, sometimes ieee12844 goes off in the
weeds, requiring me to reload both modules.
> I have the patch tested against a 2.2.14/17 and the 2.4.0-test9 kernel
> on my machine. Unfortunately I see an immense slowdown while scanning
> with the 2.4.0 kernel which is not present with 2.2.x. At the moment
> I am trying to isolate that problem (and to include Davids
> newest patch).
I'm going to try to set up CVS soon so we can stay in sync more easily.
What did it take to get 2.4 running? When I get a chance I will try to
upgrade the kernel on my supposedly 2.4-ready RedHat 7 system to try this
out myself.
David
|
