luckykar,
The above does actually explain it.
Each kernel source package will have maintainer provided 'fragments' of the over all set of configuration parameters that pertain to that source file collection. Along with any associated doc/help information.
The only 'options' that are available for that source file collection are what constitutes those fragments.
The different 'configuration' types ...
gconfig, xconfig, menuconfig, oldconfig etc are mearly Makefile targets that present those options in a variety of ways.
First they need to be collected and sorted.
Then a set of 'defaults' are applied to them. This involves such things as whether they will be flagged as modules or builtins, or if they are to be left unset. Possibly due to them representing some experimental facility, or something not commonly used.
These defaults are sourced from a file called 'defconfig' and will depend on the architecture that the kernel is being compiled on.
If you look in the directory ...
.../arch/$ARCH for your platefom you will find those files ...
defconfig <----- the defaults used.
kconfig <-------- an option fragment.
Once that collation process has been performed, make will look for an existing configuration file '.confg', resulting from a previous configuration run, in the top level of the source tree.
If found, it will use the settings there to over-ride any of the settings that the defaults may be set to.
The idea is to save your time. You may have the cpu type set specifically to suite your box and the default may involve a different setting. So why always have to reset it for each configuration run.
The closer the source version is to that used to generate the previous .config file, the less will be the over all difference in the set of options.
If that separation becomes to great, such as a .config from a kernel 2.0.x build being used as the over-ride for a 2.6.x build, make will likely spit a message informing you that it is to old and is going to be ignored.
oldconfig target:
-----------------------
curses based display.
will use a term window to only present option that are new. Those that aren't already set in a pre-existing .config file.
It presumes that you don't want to change any existing option settings, and only wish to look at whats new.
Handy to see just how many new options there are, and what they are. Or to just access a single option that may be provided by a small patch you just supplied.
It also assumes you really know your options as once set, oldconfig will just 'woosh' through a second run.
gconfig | xconfig | menuconfig:
-------------------------------------------
Presents all the available options, after the over-rides have been applied in a convieniant 'tree view' display.
The idea being that you can explore that tree view, its' various branches and consider the various choices.
You can save at any time, you can re-run as much as you want, you can reload another .config you may have saved at any time to reset the over all set.
Very handy by itself or after having run 'oldconfig'.
Very handy in terms of becoming familiar with the over all option set, and maybe setting things differently from time to time. Such as, building a second kernel of the same version but possible with some extra debug facilities built in.
gconfig uses a gtk based gui.
xconfig uses a Qt based gui.
menuconfig uses a term window.
What you did was to use a .config that was very close to the new version source that you were working with so there would be very little if any difference between the over all set of options. And as such would likely present no problems.
And 'kpkg' would have just run with the defaults and the existing over-ride.
It is a very 'slackish' way to do it, and would likely mean you would miss out on using any real enhancements that a later kernel might provide. Such as that between a 2.6.18 and a 2.6.20.
Also, a distros default kernel will usually incorporate a patch set, and will also tend to try and cover as much as possible with regard to 'driver' inclusions.
The beauty of 'rolling your own' is that you can tune things down to suite your hw setup. But you could also miss out on facilities provided by any patches that may be missing. So, look into what kind of patches that the distro provides.
With deb thats easy enough as they will be found in the '.diff.gz' file associated with the kernels source file set for a particular release (woody, sarge, etch/testing). Even if the kernel version is behind the current one, it will commonly have facilities back ported that the maintainer deems appropriate/usefull/stable.
>>
have i done it right ...
>>
You haven't done it wrong as such, but a bit lazily. If you want to compile kernels i would advise familiarising yourself with manual builds.
>>
was i supposed to use make oldconfig or make menuconfig or make xconfig
>>
Hopefully that is explained. They may work together, or separately.
>>
.config file that i pasted into the source or would it just use the default options from the vanilla kernel.
>>
As above, it will be used as an over-ride. The defaults with out a fairly recent .config can be a bit general. Such as being configured for a 'PentiumII, smp' while you may have a 64bit AMD uniprocessor
If you type ...
]$ make help
you will get some other brief info, and look in to the versioning fields at the top of your Makefile.
A ]$ make mrproper
will delete, amongst others, all files that start with a 'dot' too.
jm
, and not as difficult as a lot of people think either. But certainly not a trivial exercise. As with most things, it's just a matter of becoming familiar with, and there is only one way to do that.