I have been reading prep questions for my second unix academy exam, and there's a nuance, I'm not sure I understand it correctly.
I've been under impression from my readings of book by Evi Nemeth and from unix academy DVDs I've been watching, that kernel's modules are drivers. I think of it, as there are standard drivers that come precompiled as a part of a kernel, and some drivers that are not part of a "standard setup", so we load them when necessary as modules.
Now, I see in my readings and in the DVDs, modules and drivers are discussed on separate occasions, which makes me confused! Are they the same or they aren't? I mean, is this "module" and "driver" terminology is interchangeable and it is just figure of speech, or there's real difference between them?
The exact answer depends on the OS. I gather from your name that you are interested in Linux. With Linux, lsmod can provide a list of modules and modinfo can give you a description of a module. If you get descriptions of all of the modules, you will see that most are drivers. But not all. If you make a list of the drivers that are modules you will be missing some drivers. That's because some drivers are permanently built into the kernel without being encapsulated as a module.
A driver talks to hardware or pretends to talk to hardware. Device files like /dev/tty or /dev/null exist so your program can interface with a driver.
A module is a piece of a kernel that can be optionally loaded into the kernel.
This is from the perspective of the kernel. CUPS talks about "drivers" while Perl talks about modules. But neither means these kind of drivers and modules. So the terms get overloaded to mean lots of stuff and become a little fuzzy.
This is the best I can do to give a quick answer to a complicated question.
So, generally speaking, kernel module is a driver? Isn't it? Is there any command that can show loaded driver-device dependency tree?
lsmod shows which modules are using what other modules, though not as a tree.
It's not always as simple as one module for one device. USB needs a whole bunch of modules to do anything, plus sometimes device-specific things on top of the generic drivers -- but then again, sometimes the generic ones are enough. Sound also takes a bunch of interdependent modules to work.
There's also modules that don't do anything device-related -- like a module to let the kernel understand ext4 filesystems.
So it's really not the same thing, but often close enough for most purposes.
These modules can also be built right into the kernel, instead of being loaded from a file, too. It's possible to create a kernel that loads no modules for anything, ever. You can even build parts of a set of modules into the kernel and leave part of it out. This is sometimes important for things like ALSA, where you might want to replace some modules with updated ones later, but need certain basic parts built in.
Corona688, thanks for the clarification. Please correct me if I'm wrong.
Below are my assumptions:
user process->kernel->major device number(the driver)->minor device number->device
Let say I have device X and I want to know what driver(s) it uses (because it makes problems, or just out of curiosity). So how can it be done? It is really easy in Windows.
The kernel knows what a major+minor number means, but this often just deals with generic input layers like "SCSI disk" -- which these days can mean anything from USB to SATA to PATA, not just actual SCSI. That Linux is now able to treat nearly all disks so identically is mostly a good thing -- device names don't mysteriously change from hda to sda anymore -- but also means it doesn't tell you much about which driver's used.
Try lspci -k, that'll tell you what PCI/AGP/PCIE devices are being claimed by what modules. You can also explore the virtual /sys/ directories to find out more about the devices within.
On RedHat at least we have /usr/include/linux/major.h which documents which major number goes with which driver. And remember that there are character drivers and block drivers and one of each can use the same major number. By convention, when this happens the two drivers should be closely related. For example:
#define MEM_MAJOR 1
#define RAMDISK_MAJOR 1
is an excerpt from that header file and we have
$ ls -l /dev | awk '$5 == "1,"' | sort -k1.1,1.1 -k6
brw-r----- 1 root disk 1, 0 Jan 17 10:38 ram0
brw-r----- 1 root disk 1, 1 Jan 17 10:38 ram1
brw-r----- 1 root disk 1, 2 Jan 17 10:38 ram2
brw-r----- 1 root disk 1, 3 Jan 17 10:38 ram3
brw-r----- 1 root disk 1, 4 Jan 17 10:38 ram4
brw-r----- 1 root disk 1, 5 Jan 17 10:38 ram5
brw-r----- 1 root disk 1, 6 Jan 17 10:38 ram6
brw-r----- 1 root disk 1, 7 Jan 17 10:38 ram7
brw-r----- 1 root disk 1, 8 Jan 17 10:38 ram8
brw-r----- 1 root disk 1, 9 Jan 17 10:38 ram9
brw-r----- 1 root disk 1, 10 Jan 17 10:38 ram10
brw-r----- 1 root disk 1, 11 Jan 17 10:38 ram11
brw-r----- 1 root disk 1, 12 Jan 17 10:38 ram12
brw-r----- 1 root disk 1, 13 Jan 17 10:38 ram13
brw-r----- 1 root disk 1, 14 Jan 17 10:38 ram14
brw-r----- 1 root disk 1, 15 Jan 17 10:38 ram15
crw-r----- 1 root kmem 1, 1 Jan 17 15:38 mem
crw-rw-rw- 1 root root 1, 3 Jan 17 15:38 null
crw-r----- 1 root kmem 1, 4 Jan 17 15:38 port
crw-rw-rw- 1 root root 1, 5 Jan 17 15:38 zero
crw-rw-rw- 1 root root 1, 7 Jan 17 15:38 full
crw-rw-rw- 1 root root 1, 8 Jan 17 15:38 random
cr--r--r-- 1 root root 1, 9 Jan 17 15:38 urandom
crw------- 1 root root 1, 11 Jan 17 15:38 kmsg
crw------- 1 root root 1, 12 Jan 17 15:38 oldmem
$
The major number just tells the kernel which driver to invoke. The driver is the part of the kernel that understands its own minor numbers. But there are conventions here too.
Not all driver writers completely follow conventions. 
Perderabo,
I've been spending considerable amount of time by trying to follow your command line, but apparently, at this point, it's too much for me. I've been learning about "awk" and "sort", however... could you please elaborate in few sentences about what your specific "awk" does and how did you know where to look?
I've known for a long time that device files are in /dev. However, I forget how I came to know that. So remember this thread!! Then when someone asks you 30 years from now how you knew that device files are in /dev you can refer him to this forum. We always appreciate referrals from our members.
So I list the files in /dev. Then, with awk I select only those with field 5 equal to "1," which is the major number. And I sort the output by 1st character (which is driver type -- actually file type but same difference) and field 6 (which is the minor number).
Perderabo,
First, thanks man! Second, I do like your sense of humor. Third, I know about /dev, what I've ben asking, how to figure out that I need this or that major number. Is it something that you simply know/remember as a result of long experience, or there's some place where it all is mapped out?
Again, thanks for explaining "awk" statement. It appears like a very flexible tool, I'm going to spend some time on it.
Well I didn't really "need" any particular major number. Somehow "1" just came quickly to mind as something to use as an example. Then I was just showing the link betwen the driver and the device file (which is major number). As I said, the drivers are listed in that /usr/include/linux/major.h file so I guess you could say that "maps it out". I really don't know what info you're looking for... 
I don't think looking at the major numbers in a microscope is going to tell you what you want. The whole point of device files is to not have to care about that; they don't have a whole lot to do with what specific driver is being used. They'll tell you broad things about what class of driver, perhaps.
In a course of reading, watching DVDs and browsing it, I'm gradually start getting it. You see I'm used to windows ways... However how do you guys troubleshoot devices if there's no clear indication which driver does what? Let say I have some webcam or sound card, and how I can get the indication that driver for it is installed, and works properly? Or in a case it is installed but conflict with other driver over resources, how it can be determined? All with "lspci" ? You see in windows I have a chain to follow. I can't see this chain as clearly here so far. I realize that I'm newbie, but in windows information is readily available, and here I have to dig it out every piece by piece.
It's not like windows where you install one specific driver and have to use that hardware for life or it'll try to reconfigure itself. Linux decides which drivers to load at runtime with little to no fuss. Build every possible driver into your kernel and nearly all the time it'll choose the correct drivers and ignore the rest. I've dubbed one linux installation onto another totally different computer and gotten it to boot with no change.
There's plenty of indication which driver does what if you've ever compiled your own kernel, most selectable driver options will tell you what hardware they apply to(usually the chipset, not a brand-name). And you can tell which ones got loaded on boot via lsmod. Drivers are also frequently a lot more generic than Windows ones; sometimes one driver can handle tons of devices. Like usb-storage(flash drives), linux-uvc(webcams, cameras), ahci(SATA disk controllers), and so forth.
If anything went wrong you can check the driver messages with dmesg. As long as your system has a working console and working disk drivers you can debug from there.
This works because plug-and-play devices include device ID's to tell you which driver to use. With rare exceptions* you can't use the wrong driver, Linux drivers know what ID's they ought to talk to. The kernel can choose intelligently which driver to load, on-the-fly. Sometimes when a new device comes out, all they need to update is the ID's for the old driver to successfully use new hardware.
These ID's are what things like lspci and lsusb look at to tell you what devices you've got plugged in. They just take the ID's and consult a giant text list to tell you. This also means you don't actually have to have the driver for lspci to tell you what they are, quite unlike Windows -- which is just plain lost without an applicable driver available and no direct way to get the PCI id to even look it up.
Yes, 1) download from manufacturer, 2) follow directions, 3) as a last resort Windows Update, or else 4) complain. None of these give you much real information.
- The Realtek 8139 is an annoying exception. There's two incompatible variants with the same PCI ID. One's handled by the 8139cp module, the other by the 8139too module. When it doesn't work it tells you in dmesg to load the other driver. Another exception is video hardware acceleration, very complicated and proprietary, but since that's not needed to boot, that at least can be troubleshooted. Another is sound, because there's 1238957102351 different sound devices with the same PCI ID of "intel/amd/nvidia high-definition audio". The alsa-config utility can tell them apart fortunately.
Corona688,
Thanks for the useful info. I'm researching my system' drivers now. It is interesting!
When I mentioned Windows, I had in mind a different chain ;). In Windows from device manager you can clearly identify all hardware and follow the chain to a driver, its resources etc. Apparently Windows uses a different design. The point is, that in windows it's all very visual, so it is easy to follow, even if its internal design is flowed. It is amazing how much I learned about system at this point!
Whereas Linux is very file-oriented, and makes much of this information available via /sys and /proc instead.
# cat /proc/interrupts
CPU0 CPU1
0: 145 69 IO-APIC-edge timer
1: 152 48712 IO-APIC-edge i8042
8: 0 51 IO-APIC-edge rtc0
9: 123 20212 IO-APIC-fasteoi acpi
12: 1521 503376 IO-APIC-edge i8042
16: 2247 262236 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, hda_intel
17: 5364 885282 IO-APIC-fasteoi ehci_hcd:usb1, eth1
18: 547 148897 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, radeon@pci:0000:01:05.0
19: 0 28 IO-APIC-fasteoi ehci_hcd:usb2
22: 1023 116912 IO-APIC-fasteoi ahci
27: 0 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 10791262 10628986 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 2676499 2454427 Rescheduling interrupts
CAL: 153 128 Function call interrupts
TLB: 2406 13489 TLB shootdowns
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 69 69 Machine check polls
ERR: 0
MIS: 0
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 17
model : 3
model name : AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-82
stepping : 1
cpu MHz : 550.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit lbrv svm_lock nrip_save
bogomips : 4398.51
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
processor : 1
vendor_id : AuthenticAMD
cpu family : 17
model : 3
model name : AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-82
stepping : 1
cpu MHz : 550.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit lbrv svm_lock nrip_save
bogomips : 4398.70
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
# cat /proc/ioports
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:14.1
01f0-01f7 : 0000:00:14.1
0376-0376 : 0000:00:14.1
03c0-03df : vga+
03f6-03f6 : 0000:00:14.1
0400-04cf : pnp 00:09
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-0427 : ACPI GPE0_BLK
04d0-04d1 : pnp 00:09
04d6-04d6 : pnp 00:09
0680-06ff : pnp 00:09
077a-077a : pnp 00:09
0800-0800 : ACPI PM2_CNT_BLK
0c00-0c01 : pnp 00:09
0c14-0c14 : pnp 00:09
0c50-0c52 : pnp 00:09
0c6c-0c6c : pnp 00:09
0c6f-0c6f : pnp 00:09
0cd0-0cdb : pnp 00:09
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1000-1fff : PCI Bus 0000:80
2000-2fff : PCI Bus 0000:09
2000-20ff : 0000:09:00.0
2000-20ff : r8169
3000-4fff : PCI Bus 0000:02
5000-5fff : PCI Bus 0000:01
5000-50ff : 0000:01:05.0
6000-600f : 0000:00:14.1
6010-601f : 0000:00:11.0
6010-601f : ahci
6030-6037 : 0000:00:11.0
6030-6037 : ahci
6038-603f : 0000:00:11.0
6038-603f : ahci
6048-604b : 0000:00:11.0
6048-604b : ahci
604c-604f : 0000:00:11.0
604c-604f : ahci
# dmesg | less
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.34-gentoo-r6 (root@TheFuriousWeird) (gcc versio
n 4.4.3 (Gentoo 4.4.3-r2 p1.2) ) #3 SMP Thu Sep 23 08:23:15 CST 2010
[ 0.000000] Command line: root=/dev/sda5
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000afb8f000 (usable)
[ 0.000000] BIOS-e820: 00000000afb8f000 - 00000000afc3c000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000afc3c000 - 00000000afd70000 (usable)
[ 0.000000] BIOS-e820: 00000000afd70000 - 00000000afdbf000 (reserved)
[ 0.000000] BIOS-e820: 00000000afdbf000 - 00000000afe58000 (usable)
[ 0.000000] BIOS-e820: 00000000afe58000 - 00000000afebf000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000afebf000 - 00000000afeee000 (usable)
[ 0.000000] BIOS-e820: 00000000afeee000 - 00000000afeff000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000afeff000 - 00000000aff00000 (usable)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000e4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI 2.4 present.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x140000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-FFFFF uncachable
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 00FFF00000 mask FFFFF00000 write-protect
[ 0.000000] 1 base 0000000000 mask FF80000000 write-back
[ 0.000000] 2 base 0080000000 mask FFE0000000 write-back
[ 0.000000] 3 base 00A0000000 mask FFF0000000 write-back
[ 0.000000] 4 base 0100000000 mask FFC0000000 write-back
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] TOM2: 0000000140000000 aka 5120M
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] last_pfn = 0xaff00 max_arch_pfn = 0x400000000
[ 0.000000] e820 update range: 0000000000001000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
[ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] modified: 0000000000100000 - 00000000afb8f000 (usable)
[ 0.000000] modified: 00000000afb8f000 - 00000000afc3c000 (ACPI NVS)
[ 0.000000] modified: 00000000afc3c000 - 00000000afd70000 (usable)
[ 0.000000] modified: 00000000afd70000 - 00000000afdbf000 (reserved)
[ 0.000000] modified: 00000000afdbf000 - 00000000afe58000 (usable)
[ 0.000000] modified: 00000000afe58000 - 00000000afebf000 (ACPI NVS)
[ 0.000000] modified: 00000000afebf000 - 00000000afeee000 (usable)
[ 0.000000] modified: 00000000afeee000 - 00000000afeff000 (ACPI data)
[ 0.000000] modified: 00000000afeff000 - 00000000aff00000 (usable)
[ 0.000000] modified: 00000000e0000000 - 00000000e4000000 (reserved)
[ 0.000000] modified: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] modified: 00000000fff00000 - 0000000100000000 (reserved)
[ 0.000000] modified: 0000000100000000 - 0000000140000000 (usable)
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] init_memory_mapping: 0000000000000000-00000000aff00000
[ 0.000000] 0000000000 - 00afe00000 page 2M
[ 0.000000] 00afe00000 - 00aff00000 page 4k
[ 0.000000] kernel direct mapping tables up to aff00000 @ 16000-1b000
[ 0.000000] init_memory_mapping: 0000000100000000-0000000140000000
[ 0.000000] 0100000000 - 0140000000 page 2M
[ 0.000000] kernel direct mapping tables up to 140000000 @ 19000-1f000
[ 0.000000] ACPI: RSDP 00000000000fe020 00024 (v02 HP )
[ 0.000000] ACPI: XSDT 00000000afefe120 0005C (v01 HPQOEM SLIC-MPC 00000003 01000013)
[ 0.000000] ACPI: FACP 00000000afefd000 000F4 (v04 HP 3045 00000003 MSFT 0100000D)
[ 0.000000] ACPI: DSDT 00000000afef1000 0850E (v01 HP 3045 F0000000 INTL 20051117)
[ 0.000000] ACPI: FACS 00000000afe61000 00040
[ 0.000000] ACPI: HPET 00000000afefc000 00038 (v01 HP 3045 00000001 MSFT 000F4240)
[ 0.000000] ACPI: APIC 00000000afefb000 00084 (v02 HP 3045 00000001 TFSM 000F4240)
[ 0.000000] ACPI: MCFG 00000000afefa000 0003C (v01 HP 3045 00000001 TFSM 000F4240)
[ 0.000000] ACPI: BOOT 00000000afef0000 00028 (v01 HP 3045 00000001 ? 00000001)
[ 0.000000] ACPI: SLIC 00000000afeef000 00176 (v01 HPQOEM SLIC-MPC 06040000 LTP 00000001)
[ 0.000000] ACPI: SSDT 00000000afeee000 00386 (v01 AMD PowerNow 00000001 AMD 00000001)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] Scanning NUMA topology in Northbridge 24
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-0000000140000000
[ 0.000000] Initmem setup node 0 0000000000000000-0000000140000000
[ 0.000000] NODE_DATA [0000000100000000 - 0000000100004fff]
[ 0.000000] [ffffea0000000000-ffffea00045fffff] PMD -> [ffff880100200000-ffff8801037fffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x00140000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[7] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009f
[ 0.000000] 0: 0x00000100 -> 0x000afb8f
[ 0.000000] 0: 0x000afc3c -> 0x000afd70
[ 0.000000] 0: 0x000afdbf -> 0x000afe58
[ 0.000000] 0: 0x000afebf -> 0x000afeee
...
(on and on for 1000+ lines)
---------- Post updated at 08:13 PM ---------- Previous update was at 08:12 PM ----------
The contents of /sys/ are so low-level I don't understand much of them but you can find quite a lot in there, apparently.
Corona688,
thank you for the post. I spent three days learning about the commands and info they pull out. I'm still on it. Thank man!
BTW, is there a database or repository to check on existing drivers before buying a device? My understanding that in most cases Linux drivers aren't provided by manufacturers but mostly by a community. I found numerous discussion forums for Ubuntu and some HCLs.
And, is there an issue of using old drivers with newer versions of kernel, or they are compatible? It's my understanding that 64-bit and 32-bit require different drivers.
Are Linux drivers universal and fit into all Linux flavors or let say Fedora needs one driver and Debian another?
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.
Corona688, thank you man! My head is spinning at his point. I feel like five years old taken to a planetarium. They show you the planets on a fake night sky and it appears nice and easy, feel exciting... until you start asking them questions... they tell you that you really get it only after years of dedicated learning 
I'm taking a wine break today