On Thu, Jan 30, 2003 at 06:18:35PM +0100, Erik Mouw wrote: > On Wed, Jan 29, 2003 at 09:21:02PM +0100, Jan Hudec wrote: > > On Wed, Jan 29, 2003 at 07:56:16PM +0100, dballester@kernpharma.com wrote: > > > 2 Make a soft link /usr/src/linux that points to the decompressed tree. > > > > No! It used to be done that way in ancient times and /usr/include/linux > > was a link to /usr/src/linux/include/linux. But it turned out, that it > > does not work! /usr/include/linux must include the headers libc was > > compiled against and NOT those of current kernel. Thus they shell be > > a copy and linux sources may be placed wherever you want > > The original poster was talking about /usr/src/linux, not > /usr/include/linux. It is not necessary to make a softlink from > /usr/src/linux to the actual tree, but it doesn't hurt. Some external > kernel modules (ALSA for linux-2.4 comes to mind) expect the kernel > sources to live in /usr/src/linux. Most of those external kernel > modules can be told to look somewhere else, but for convenience a > softlink from /usr/src/linux is nice. Your point about > /usr/include/linux is valid, though. I _know_ he was talking abou /usr/src/linux. /usr/include/linux was a reason for that and is now depreciated. Some external modules sources have it as a default path to look for linux, which can be overriden in configure or makefile, but all such modules are BROKEN, because the default path is /lib/modules/'uname -r'/build, which is a link created by make modules_install to the source tree. That is, such a link exists for 2.4.x kernels, in times of 2.2.x, /usr/src/linux was not depreciated yet. > > > 3 If any patch will be installed use patch -p1 > > > > Right. > > Depends, I've seen patches from clueless hardware vendors that were > diffed in the kernel tree itself and would need -p0. Just check the > patch, if it's a unified diff, it's pretty easy to figure out. Another > important thing is that you first use the --dry-run flag to see if the > patch applies cleanly. Ok, may be. I have not seen such patches, but they may exist. > > > 4 make mrproper ( clean ) > > > > BEWARE HERE! When you patch a kernel from previous version, you usualy > > want to keep the config and just check new options. Unfortunately make > > mrproper removes .config, so your configuration would be lost. So you > > have to backup your .config file using a name not matching .config* > > > > Btw: make clean usualy works. If it does not, then do make mrproper. > > (sometimes removing .depend and .hdepend files helps too) > > Rule of thumb: when upgrading to another kernel version, backup > .config, run make mrproper and put back .config. May happen in other cases too. Like when you want to try another compiler. And since kernel version is just a big patch, it may be needed for other larger patches too. So I would say, for safety's sake, do it when you apply new patches. > > > 5 Configure the kernel using make config, menuconfig or xconfig > > > > For 2.5 there is kconfig instead of xconfig and it requires libQt :-(. > > Config and menuconfig are the most tested configurators, other stuff > occasionaly breaks (especially xconfig, in my experience). If you have > saved your .config file from your previous kernel, running "make > oldconfig" only asks you configuration options for things that changed. Yes... mentioning make oldconfig is a good point. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@ucw.cz> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
