In other words is supported hardware determined by the kernel version or is there some other mechanism that determines what hardware is supported? Thank you for your help.

To some degree this is true. Let me give you an example.

Your favorite graphics card maker comes out with a new card. Kernel support may ( probably ) not be there. ( Some new hardware feature ). So, the developers have to get their hands on the hardware, and any info form the maker. They write and test new code, and integrate it into the kernel. That will be for the latest kernel, and possibly ( no guarantees here ) back ported to previous kernels. Drivers are written. Now it works.

Back porting may not be practical, do to code design, and writing and test design costs. So, newer kernels can and will support new hardware. Old ones may not.

1 members found this post helpful.

Based on my understanding of what you said can I make the following assumption: If distro A and distro B use the same kernel can I assume they both support the same hardware?

This is actually what I want to know and my original reason for making this thread. I may have asked poorly, my bad.

To find kenel number I enter: uname -a

Thank you for your reply.

Hi,

'uname -a' will get all information. 'uname -r' will get the version numbers. Do a 'man uname' online or open a terminal an do 'man uname. That way you can understand the options available.

1 members found this post helpful.

Thanks, I knew that. I've been checking live discs recently for kernel information and I like seeing all information.

Thanks for the man pages link too.

OT: I had to think twice about what "Member Response" might mean.

I would say yes to this assumption. Understand you would have to make sure the correct modules are loaded on both for everything to work and compiled against the correct kernel headers for each distro. Having support for the module doesn't mean it is loaded.

Once you know the hardware, and what KLM ( driver ) you need, use lsmod command to verify its loaded.

1 members found this post helpful.

IIUC kernel number is the primary indicator of what hardware is supported however differences in how the kernel is compiled (I guess) might mean some drivers aren’t loaded. Is this correct? I have never compiled anything so I’m making assumptions.

I have read that modprobe can be used to load drivers using this procedure. If this is true can a driver be loaded even though support for it is not compiled in the kernel?

The reason I still don’t have a good grip on this is I see files ending in “.ko” in /lib/modules that I assume are drivers. So if the drivers are in there does that mean it’s possible to add more drivers? Or are the drivers built into (compiled) the kernel?

Or is it that support (a.k.a. compatibility?) must be present (compiled?) in the kernel for drivers to be able to be loaded from /lib/modules ?

Apologies for my ignorance. Thank you for your patience.

Sorry, don't know the answer here.

Yes, you use modprobe to manually load a module. As far as 'support in kernel' this to me means the kernel can load the module. The module has all the support for the hardware it is for. I don't know kernel architecture well enough to go further.

Yes, they are drivers compiled for your kernel.

Yes you can add more drivers.

You can compile a module into the kernel. If you do, no need to load a module, the code is in the kernel. With linux you have a choice of, a. load a module form a .ko file; or b. compile it in the kernel, then you don't need to load the module.

You have the choice, load the modules, or compile in the kernel. There are reasons to do either. If you compile just what you need in the kernel, linux screams speed. You would never ask a processor to run code for devices not installed.

To accomplish this requires detailed knowledge of your hardware. You can take a kernel form your distro, remove all code not required by your system, and load just what you need. The big distros compile kernels that will run on most systems, so you get a lot of code loaded you will never need. The reason they do it is for the noobs ( like me ) that just want it to install and run.

I run slackware on my main system. The first kernel I installed was called 'huge'. It has everything, but the kitchen sink in it, runs on almost any PC based system. After you install, it is recommended you re-compile the kernel, remove what you know you don't want, compile it for your architecture, i686, amd64 etc... and run that. I have done it, not all that difficult, if you follow the docs for slackware.

I took out a lot of stuff, for cards I know I don't have, added support for a few things I do have.

Hope this helps.

1 members found this post helpful.

If they use the exact same kernel, yes. But just because they have the same version number does not mean they are the same kernel. Many distributions patch the stock Linux kernel to add support for hardware that is not yet included in the kernel.

1 members found this post helpful.

Think of it this way:

Drivers can be compiled in 2 ways, they can be loadable modules or they can be built-in. Modules are usually loaded automatically as needed.

You cannot unload built-in drivers, but some can be disabled via the kernel command line. This can sometimes cause problems, because probing for devices that don't exist can cause hangs or a slower boot.

I usually compile drivers built-in only if they are needed on boot. For example the filesystem drivers are needed in order to load the kernel from disk. If you don't build these in, the kernel won't boot, it is a common issue. The rest of the drivers are modules.

Another option is to compile everything as a module and make an initrd. An initrd allows you to load the modules as well as the kernel into RAM, thus allowing the kernel to boot.

Rarely there can be conflicts between modules, so one will override the other (usually the wrong one takes precedence) and things will not work right.

If you're trying to compile a kernel, keep in mind that it is difficult to get it right the first time. Personally, I have to recompile it many times to get everything working properly. However, this has the benefit of potentially making the system more stable and making it boot faster.

Be careful with experimental drivers and especially of the staging drivers. These are much more likely to cause problems, but many will still work ok. I mean I've been using the realtek wifi staging drivers for quite a while and nothing bad has happened. The same cannot be said for the broadcom staging drivers.

1 members found this post helpful.

IIUC I think the following is true:

Modules (a.k.a. drivers) can be built into the kernel or loaded from /lib/modules.

Users can add modules by placing them in /lib/modules and then loading them with modprobe.

Modules must be compiled for a given kernel in order for them to be compatible with that kernel. If a module is not compiled for a given kernel it is incompatible with that kernel.

If these statements are correct my thread is solved. Thank you all very much.

PS: I’m not looking to compile anything yet, I’m just trying to understand the relationship between modules and kernel number as a means to gain insight about what hardware is supported.

At the most basic level, all of your hardware is controlled by setting a bunch of internal switches and watching an even bigger bunch of blinking lights. The kernel is the only part of the system that is allowed to do that. But, since every piece of hardware can be different, the kernel uses drivers to manipulate the hardware itself. These drivers can be built-in to the kernel or they can be loadable modules.