primax: Thread: Kernel Module for Primax Scanners

I'm going to translate the 0.93 BETA2 driver in to a character device
kernel module for kernel 2.2.x (possibly 2.4.x)
Is there any effort already in place in this direction?
Are you aware of any other non-scsi-scanners kernel modules projects?
Have you any advice?

Many Thanks,
Simo.
-- 
####@####.####
http://www.geocities.com/SiliconValley/9757

Hi

> Are you aware of any other non-scsi-scanners kernel modules projects?
I did one. But only because my scanner uses IRQs which don't work in user space.

> Have you any advice?
Yes: Let it be.

Why? because:

1. You would depend on the Kernel Interface: 
If something on the kernel stucture changes (which happens), you'll have to
change your driver, too.

2. You become system dependend:
What about FreeBSD? Or other OSes...
 
3. The sane guys don't add these to the sane package (because of 2.).

4. realtime problems.
kernel module sounds like realtime. But not with a char device. There is the
need for an extra user space (non-realtime) programm, getting the data from the
device. But the data comes asynchronous to the user space program. so where to
put the data. Perhaps a buffer, but as char device you schouldn't alloc Megs of
buffer memory (and you won't know how much you really need). 

5. the debugging
Ever tried to debug a kernel module...

Perhaps you should spend your energy for something different.
Here an idea:

What about a scanner daemon. It could make itself with nice() to nearly
realtime (if needed) and write the data to a file in /tmp (no buffer size
problem). Then you could write a sane backend communicating with the daemon
via pipes. It could read the data from the file while the daemon is still
writing to it (like tail). Ah- and the daemon could also control the lamp. It
could be turned off after 15 min of not using the scanner. This would be
system independent and you could recycle the existing programm, just change the
output and wrtie a controll interface.

And belive: writing a daemon is at least as exciting as writing a kernel module.

so far with my advice. 

Bye 

Andre

On Sun, 25 Jun 2000, Simo Sorce wrote:

> I'm going to translate the 0.93 BETA2 driver in to a character device
> kernel module for kernel 2.2.x (possibly 2.4.x)
ok but when it will be SANE ready ? (user or kernel space driver) :-)

> Many Thanks,
> Simo.

-- 
Arkadiusz Miśkiewicz         http://www.misiek.eu.org/
PLD GNU/Linux [IPv6 enabled]  http://www.pld.org.pl/

On Mon, Jun 26, 2000 at 11:14:18AM +0200, Arkadiusz Miskiewicz wrote:
> ok but when it will be SANE ready ? (user or kernel space driver) :-)
making it a SANE module isn't highest priority. Maybe it'll never be a real
SANE module I've thought about something like a Meta-backend which fetches
the image data from our driver program, this would be easier than restructuring
the whole thing to make it a "real" SANE backend.

-- 
Christian Ordig             | The Primax Scanner Driver Project for Linux/UN*X |
Germany                     |   http://thor.prohosting.com/~chrordig/Primax/   |

Onjo wrote:
> 
> Hi
> 
> > Are you aware of any other non-scsi-scanners kernel modules projects?
> I did one. But only because my scanner uses IRQs which don't work in user space.
> 
> > Have you any advice?
> Yes: Let it be.
> 
> Why? because:
> 
> 1. You would depend on the Kernel Interface:
> If something on the kernel stucture changes (which happens), you'll have to
> change your driver, too.
> 
> 2. You become system dependend:
> What about FreeBSD? Or other OSes...
> 
> 3. The sane guys don't add these to the sane package (because of 2.).
> 
> 4. realtime problems.
> kernel module sounds like realtime. But not with a char device. There is the
> need for an extra user space (non-realtime) programm, getting the data from the
> device. But the data comes asynchronous to the user space program. so where to
> put the data. Perhaps a buffer, but as char device you schouldn't alloc Megs of
> buffer memory (and you won't know how much you really need).
> 
> 5. the debugging
> Ever tried to debug a kernel module...
> 
> Perhaps you should spend your energy for something different.
> Here an idea:
> 
> What about a scanner daemon. It could make itself with nice() to nearly
> realtime (if needed) and write the data to a file in /tmp (no buffer size
> problem). Then you could write a sane backend communicating with the daemon
> via pipes. It could read the data from the file while the daemon is still
> writing to it (like tail). Ah- and the daemon could also control the lamp. It
> could be turned off after 15 min of not using the scanner. This would be
> system independent and you could recycle the existing programm, just change the
> output and wrtie a controll interface.
> 
> And belive: writing a daemon is at least as exciting as writing a kernel module.
> 
> so far with my advice.
> 
> Bye
> 
> Andre

Excuse me all for not responding before but my home modem has been fried
by a lightning :(
Your conclusions are mostly right, but the (1) is yet taken in account,
for the (2) when bsd men will leave more freedom on development, maybe a
porting will be done :P
To use the kernel module I will need a user space program so the sane
backend would use this and not the kernel module directly.
But the point I care more is the (4); I really prefere the kernel module
which is parport(module) aware and my operate correctly sharing my
parport with my laser printer and my Zip drive.
I'm now aware of what means (5) as a first module is ready. Just now it
will only recon the scanner, switch on/off the lamp and move back the
carriage if it is not in starting position. I made this by "only"
locking down my machine two times (becuse of incorrect return on the
init_module() function.
Operating with module is not so bad and loading and unloding is as
simple as launching and killing a program.
However at now I'm analizing the color tables and calibrating function
(any clear paper on theses to speed up things?)

Bye,
Simo


-- 
####@####.####
http://www.geocities.com/SiliconValley/9757