Use the name argument almost the same in all LKM types. Maintain
the current behavior for the external (e.g., modstat) name for DEV,
EXEC, and MISC types being #name ## "_mod" and SYCALL and VFS only
#name. This is a candidate for change and I vote just the name without
the "_mod".
Change the DISPATCH macro to MOD_DISPATCH for consistency with the
other macros.
Add an LKM_ANON #define to eliminate the magic -1 and associated
signed/unsigned warnings.
Add MOD_PRIVATE to support wcd.c's poking around in the lkm structure.
Change source in tree to use the new interface.
Reviewed by: Bruce Evans
Add support for LKM operation.
Change M_NOWAIT on buffer memory allocation to M_WAIT in hopes we'll be
able to get ourselves a nice fat buffer from the kernel if we suspend.
Note: The LKM support looks kinda screwy in two areas, where I found
problems with the kernel proper. First, calling dev_attach()
at module load time will cause a panic. I haven't investigated.
Secondly, I had to manually call qcam_drvinit() to register the
device softc structure by hand at module load time. This seems
bogus, it should be called as a core part of the module load
process for character/block device drivers.
- split driver into FreeBSD specific and camera specific portions
(qcamio.c can run in user mode, with a Linux "driver top" etc,
and qcam.c should be trivial to port to NetBSD and BSDI.)
- support for 4bppand bidirectional transfers working better
- start of interleaved data-transfers byte-stream decodes (some of this
stuff has been pulled out for the moment to make it easier to debug)
At this point, anyone who wants to port it to other platforms should feel
free to do so. Please feed changes directly back to me so that I can produce
a unified distribution.
for me, but has gotten a bit flakey in bidirectional parallel port mode.
Fix a bug in bidirectional parallel port transfers, more work is still
needed here (testers welcome).
Minor cleanup.
vs unidirectional transfer modes. The kernel handles hardware, user mode
programs shouldn't get in the way.
This cleans up some really ugly grots that I hated too. :-)
Suggested by: Sujal Patel <smpatel@wam.umd.edu>
* this is my unoptimized driver, it works fine, it's not as fast as it
* could be (yet) -- I have yet to merge in ideas from other QuickCam
* developers.
