Linux – Do different distros (but same kernel ver) have same hardware support

Driver support works the same way as with all of open source: someone decides to scratch their own itch.

Sometimes the driver is supplied by the company providing the hardware, just as on Windows. Intel does this for their network chips, 3ware does this for their RAID controllers, etc. These companies have decided that it is in their best interest to provide the driver: their "itch" is to sell product to Linux users, and that means ensuring that there is a driver.

In the best case, the company works hard to get their driver into the appropriate source base that ships with Linux distros. For most drivers, that means the Linux kernel. For graphics drivers, it means X.org. There's also CUPS for printer drivers, NUT for UPS drivers, SANE for scanner drivers, etc. The obvious benefit of doing this is that Linux distros made after the driver gets accepted will have support for the hardware out of the box. The biggest downside is that it's more work for the company to coordinate with the open source project to get their driver in, for the same basic reasons it's difficult for two separate groups to coordinate anything.

Then there are those companies that choose to offer their driver source code directly, only. You typically have to download the driver source code from their web site, build it on your system, and install it by hand. Such companies are usually smaller or specialty manufacturers without enough employees that they can spare the effort to coordinate with the appropriate open source project to get their driver into that project's source base.

A rare few companies provide binary-only drivers instead of source code. An example are the more advanced 3D drivers from companies like NVIDIA. Typically the reason for this is that the company doesn't want to give away information they feel proprietary about. Such drivers often don't work with as many Linux distros as with the previous cases, because the company providing the hardware doesn't bother to rebuild their driver to track API and ABI changes. It's possible for the end user or the Linux distro provider to tweak a driver provided as source code to track such changes, so in the previous two cases, the driver can usually be made to work with more systems than a binary driver will.

When the company doesn't provide Linux drivers, someone in the community simply decides to do it. There are some large classes of hardware where this is common, like with UPSes and printers. It takes a rare user who a) has the hardware; b) has the time; c) has the skill; and d) has the inclination to spend the time to develop the driver. For popular hardware, this usually isn't a problem because with millions of Linux users, these few people do exist. You get into trouble with uncommon hardware.

If you have a /proc filesystem, the file /proc/modules exists if and only if the kernel if compiled with module support. If the file exists but is empty, your kernel supports modules but none are loaded at the moment. If the file doesn't exist, your kernel cannot load any module.

It's technically possible to have loadable module support without /proc. You can check for the presence of the init_module and delete_module system calls in the kernel binary. This may not be easy if you only have a compressed binary (e.g. vmlinuz or uImage). See How do I uncompress vmlinuz to vmlinux? for vmlinuz. Once you've managed to decompress the bulk of the kernel, search for the string sys_init_module.

Note that if modules are supported, you'll need additional files to compile your own modules anyway: kernel headers. These are C header files (*.h), some of which are generated when the kernel is compiled (so you can't just take them from the kernel source). See What does a kernel source tree contain? Is this related to Linux kernel headers?