The closest thing Linux has to a central repository is the kernel source itself(and the information provided by make menuconfig). But it's usually chipset-oriented, not device-oriented -- it will tell you the driver supports Realtek xxxxxx, not that it supports So-And-So Generic Brand Name Network Card. So I usually just google it, and that tells me what module to use if any, and from there I can find info in the kernel configuration utility. Correct. The same community that maintains the Linux kernel I think, since almost all of Linux's open device drivers are bundled with the kernel source code. When you update your kernel, you update your drivers too, for they come with it. (third-party drivers excepted.) You can have drivers for several different kernels installed and they won't overlap because the kernel knows what version it is and loads from different directories (/lib/modules/kernel-version/...) This is where third-party drivers go too, so when you update your kernel, if you didn't reinstall the third-party driver, the new kernel simply won't find it.

Binary drivers from third parties usually need to be updated for new kernel versions. They often come in two parts, a binary part that changes less often, and a small stub of source code to tie it to the kernel. It's this stub that gets compiled to turn the binary into a driver Linux can load.

Even then, sometimes a newer kernel means you need a newer binary too. A newer kernel can mean architecture changes inside the kernel which they have to re-engineer something to fit. Yes, they are very different. Broadcom for instance has two versions of its proprietary driver, one for 32-bit and one for 64-bit Linux systems. A 64-bit kernel can run 64-bit and 32-bit programs, but a 32-bit kernel can only run 32-bit programs.

Other architectures need their own drivers too. SPARC and PPC and ARM all need their own drivers. Even if it's the same device driver being compiled, the executable code naturally ends up being very different. That depends. The Linux kernel is extremely configurable, and radically different configurations of the kernel may not work with drivers meant for a different configuration. If at all possible you'd want a device driver built inside, or at least using the same source code and configuration used to build your kernel.