...making Linux just a little more fun!
From Jason Creighton
Answered By: Thomas Adam, Ben Okopnik
I wanted a photo off my parent's digital camera. They have Windows ME. I don't know if ME's USB support is seriously flaky or what, but only one USB device has even worked consistently with that computer (a scanner).
Windows was hanging on me, not working, making me mad and in general doing the things it's good at.
Enter Linux. I install libusb, libgphoto2, and gphoto2. I compile the usbcore module, and then try to use gphoto2. It can't see the camera. I fiddle with things awhile, and it "doesn't work".
Had I read Crux's (my distro) README for libusb more carefully, I would have seen I need usbfs. Enable that option, recompile the kernel modules, install 'em, modprobe, and IT WORKS! I can download photos, and it just works. No need to use some stupid kludged-up vender-enforced GUI.
[Ben] Wow, nice. Took me several net searches and a good bit of luck - I ran across exactly one discussion of this, but it was exactly what I needed, including the fine details. This was, in fact, the first time I ever got a USB-to-camera connection to work with Linux (not that I'd tried a whole lot of times previously, but it was once or twice at least over a couple of years.) I'd never seen any standard documentation for it, and kudos to the Crux folks for writing it.
I love Linux.
 I have an uptime of 35 days, which is the longest I've managed to get between me wanting to try new kernels, the efforts of the power company and well-meaning family members.
So I really didn't want to compile a new kernel and have to reboot. So I just added the usb kernel module to my kernel config, did a "make modules && make modules_install" and modprobe'd the modules into the running kernel, which is the same version and was built from the same source-tree. Is that a good idea? I mean, everything appears to work fine, but will enabling a module ever require you to rebuild the kernel itself?
[Thomas] No, not unless the module relies on an option that you need to statically compile into the kernel and have not already done so -- an isolated case, so you should be fine.
As to whether it is a good idea, module loading works by looking at the module's symbol information, which matches the version of your current running kernel. If the version of the module is the same as `uname -r`, then it will load quite happily, whether it was compiled at the same time as the kernel or ten months afterwards.
But what also happens is that the compiler versions that were used to compile the kernel, and the new modules have to match exactly. If they don't, then loading the module(s) simply will not work.
Since you specified "ever", the answer is "yes". But far from always. If, for example, you were to enable the entire Ethernet category (which had been disabled in the last compile), build some driver modules, and attempt to laod them, I can just about guarantee failure; the running kernel would be missing the "hooks" for the whole Ethernet category. However, if the category had been enabled previously and you just added a specific card driver to the ones that you'd compiled previously, chances are high that you wouldn't need to reboot. Either way, there's no harm in trying; in the worst case, you'll get a whole bunch of "Undefined symbol" messages when you try to load the module.
 It occurs to me as I write this that I could have typed "make modules modules_install" but oh well.
[Ben] Yup. Note that with 2.5 and above, there's no need to do "modules"; it's part of "make". My preference, if I was going to do the above, is to go ahead and run "make", then "make modules_install install"; that way, if the module does fail to load, all I do is "sudo reboot".
 Correct term? I mean, I extracted the linux-2.4.20 tarball to /usr/src, and I built these modules from that as well as the kernel I'm running now.
[Thomas] Correct term. You should also run 'depmod -a' after the modules_install part so that the kernel knows of their existence properly.