Re: [hpoj-devel] kernel drivers broken with SMP

[<pa...@rc...>]

Hi, Gerhard and Burkhard.  Thanks for providing the information regarding
the SMP and 2.4-kernel problems, which seem to be interrelated.  You seem
to have a much better understanding of kernel issues than I do.  If either
or both of you would be willing to work towards a solution to these problems,
that would be greatly appreciated, and would leave me more time to develop
scanning support for the scrollfed MFPs, which I started working on last week.
:-)

ger...@mc... said:
> 1. A driver, that has been compiled for an UP kernel cannot be used
> with
>    an SMP kernel (and vice versa).
>    An SMP module must be compiled using kernel header files
>    which are configured for SMP (-> CONFIG_SMP) and with the
>    compiler flag -D__SMP__

>    Is the current Makefile prepared to compile either SMP or UP
> modules? 
Good point.  Currently, ieee12844/Makefile.in starts with the following lines:
	SMP=
	# SMP=-D__SMP__

	CFLAGS = -O @INCLUDE_CMDLINE@ -Wall -Wstrict-prototypes -D__KERNEL__ \
		 -DMODULE -DEXPORT_SYMTAB $(SMP)
As it stands now, the __SMP__ symbol is not passed to kernel includes.
So, Alexander, one thing you could try is uncommenting out the second line.
If you modify Makefile, then you can recompile right away but the change
will be lost the next time you run the ./configure script.  If you modify
Makefile.in, then you will need to re-run ./configure before you try
recompiling.  Since this problem appears in all versions, you might as well
use the latest (0.6).

Many thanks also to Damcha and Alexander for reporting these problems and
bearing with us as they hopefully get fixed.

For the longer term, I'm exploring options to replace as much as possible
of the kernel-mode drivers with a user-mode daemon that continues to support
MLC and parallel as today and adds support for 1284.4 and USB.  The low-level
interfaces to this daemon would be Unix-domain sockets, so it would have
similar semantics to the AF_MLC sockets used today.  A user-mode approach
would provide better stability, maintainability, and portability due to less
dependence on the Linux kernel interfaces.  But I don't have any definite
plans as of yet, so it would still be good to press on with resolving these
problems with the current code.

BTW, I changed the hpoj-devel mailing list so replies are sent to the list,
the way it was with bstc.net.  Therefore, it's no longer necessary to
"reply to all" to direct replies to the list.  I hope nobody will be upset
by this change.

David