Well, just from your questions, I can tell that you are a bit confused. You don't "install" a module. You load it. This does not become part of the kernel, but merely allows the kernel to interact with the module to interact with the hardware.
You will need to modprobe your sound card, yes.
You add the whole command, just like you asked, into modules.conf.
Using your example, and the defaults for most sound cards, here is the complete modprobe command as you would probably enter it.=:
Code:
modprobe snd-via82xx io=0x220 dma=5 irq=1
This tells the kernel that we are using snd-via82xx as a module to interact with your soundcard, and that the soundcard has an IO address of 0x220, it's DMA channel is 5, and the Inturrupt that it will use to tap the processor is 1. These parameters are used mainly for loading HW modules, almost never for software, unless required. (If you don't know, you don't need it. Mainly for those fine folks out there building stuff for us that need to test it first.)
So, for instance, if you wanted to add NTFS support to your kernel by loading a module, the following would do just fine:
The relationship of kernels and modules are as follows:
A kernel begins life as what is known as source code. You have probably seen this before on some of the linux sites, just about all of them, really. Source code is the human-readable/editable format that software is written in. In order for this to be more than a glorified text document, it has to be compiled. A software compiler, in most cases for us in the linux world, is known as GCC (GNU C Compiler).
Compilers take this human readable format, and turn it into machine language, that is to say, software that can be used and understood by your machine.
All kernels must be compiled, whether you do it, or it is done for you by your distro's creators.
If you download the source code for a kernel, you have tons of files, that after compiled, will make up a kernel image that can be used to run your machine.
The cool thing about a kernel, though, is that there are options before you compile. You can tell the kernel exactly what you want the file image to be able to do.
This is done by changing the options. I won't get into detail, as there are 1001 posts here on how to compile your kernel, but, the quick and dirty is like this.
You can go into the kernel, and for every availible option (there are hundreds - most having to do with supporting a specific feature - networking, file sharing, encryption, hardware support, etc) you have three choices. You can do nothing, you can compile it as a module, or, you can add it to your kernel image.
Doing nothing - the results are obvious.
Compiling as a module, when you compile the kernel, you give it an extra command "make modules" which will build the actual module files for the options that you chose to build that way. This means that the module files on your computer are built by and for the same process that built your kernel. This means that they are totally compatable. This process creates the modules for you to load later. This is why it is not necc. to edit anything to let the kernel "know" that you "installed" a module. The kernel knows that they are there, they were born at the same time, as kinda second cousins.
The third option, is to compile it into the kernel, and the kernel image that you build, will have support for your chosen option without loading a file. Very simply put, it takes the code from the module file, and inserts it neatly into it's own code, so that they become one.
This is great for somethings, but maybe not for all. As I said before, since they basically become "one" - this means that for every option that you compile into your kernel, the larger the image will be, and depending on your machine, it might not be able to handle a kernel that is too large. So, you have some flexibility.
That is the whole point of linux. Flexibility. It was made to do just about anything on just about anything, and is entirely customizable. This is the beauty of it.