primax: Kernel Module for Primax Scanners
Subject:
Re: Kernel Module for Primax Scanners
From:
Simo Sorce ####@####.####
Date:
9 Jul 2000 08:29:56 -0000
Message-Id: <39683781.2C28DE8F@tiscalinet.it>
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
