Hi everybody
I want to install a driver named typhoon which is in the /usr/src/linux2.4.21-4.0.1.ELsmp/driver/net/typhoon.c
What process should I do to make it typhoon.o

Use make menuconfig and check that driver as a module.
Save the kernel config changes
make modules


That should only make the modules that aren't already created. Always has for me

I want to compile it through makefile option.I have similar docoument with me but unabel to understand it.Below it the example which shows how to compile a single module


cd /usr/src/linux
cp Makefile Makefile.my
vi Makefile.my
# And comment out the line having 'SUBDIRS' and add the
# directory you are interested, for example like fs/autofs as below :
#SUBDIRS =kernel drivers mm fs net ipc lib abi crypto
SUBDIRS =fs/autofs
# Save the file Makefile.my and give -
make -f Makefile.my modules
# This will create module autofs.o
# Now, copy the module object file to destination /lib/modules
make -f Makefile.my modules_install
# And this will do 'cp autofs.o /lib/modules/2.4.18-19.8.0/kernel/fs/autofs'


But I am unable to compile single module.Plz any one help me to fulfill my above task

The aforementioned cryptic document notwithstanding, the message should be clear:

• do not try to compile individual modules.

Kernel modules are removable parts of what must be regarded as "a single program: the kernel." All of the pieces of "that single program" must match exactly, whether they are part of this module, or that module, or part of the resident kernel. The one and only best-way to assure that is to recompile "the kernel," all at once (or as make decides), modules-and-all.

If you compile "a single module" and don't get the rest of it, then the binary kernel image may be out-of-sync. And let me put it this way: I don't think you really want to be debugging an unstable or stone-dead system. Not if you can avoid it.

Consider doing this:

• from /usr/src/linux, as root ...
• mv .config foobar
• make distclean
• mv foobar .config
• make
• make modules_install
• make install
• (verify or adjust LILO or GRUB if and as needed)
• reboot

Or, if you are using binary packages|RPMs, install the correctly-versioned package containing that module.

Be aware that, if you are basing your system on packages|RPMs, you probably should continue to do so because, in my experience, the source-code supplied with such distros may or may not produce an identical kernel to their binary when compiled from their source on your hardware. Many subtle things, including optimization settings and compiler version differences, can introduce devilish binary incompatibilities that can cause instability or system failure... even if "they're doing everything right and you're doing everything right and the source-code is exactly the same." You can "make a clean break" from packages|RPMs with respect to your kernel, if you so choose, or you can stick with packages, if you so choose, but you should not mix the two methods.

ummm just do make menuconfig then find the driver you want to load a a module, then do make modules; make modules_install and reboot


Doing make clean and all that crap is a waste of time and doing just make modules; make modules_install takes about 10 seconds and doing the other way on anything less then a amd 3200 or p4 3.0 takes 20 minutes

I want to compile it through makefile option,which I mention above

I would have to disagree here, as I've been running "mixed" environments since some years ago with Red Hat and Debian distros... Granted that building from a "kosher" source tree in SuSE is a pain in the butt, as their structure is rather cryptic not to mention "non-standard". You can keep as clean or as dirty as you actually want your system regarding the kernel. It is best to keep it clean, though.

I usually "run" two kernels, the current binary provided kernel and my custom made kernel without any issues. Maintaining the custom ones is a pain, though, as you have to keep track of all the files in /boot, /lib/modules/<your_kernel> and /usr/src/<your_kernel> by had, which can be a rather laborious housekeeping. Actually the ability to have two or more kernel images installed, and boot into any one of them (provided they work) is what I find as great strength and flexibility in Linux. I tried to do that with BSD once, and quickly ran into problems I had never seen in Linux... maybe Linux is more error tolerant than BSD in that regard, or I did not fully understand what I was doing in BSD, plus that was some time ago.

In any case, I would have to agree with you in that unless a user (any user) is willing to do some serious work in terms of maintainance to keep their system clean and running fine, mixing binary and source installed kernels is better avoided.