kernel's System.map
Stupid question, but what exactly tells the kernel to use which System.map? I notice the kernels supplied by SuSE are named like this, System.map-2.4.16-4GB but if I compile my own it typically gets created as just System.map. Now if I wanted to use the same nameing to keep track of them, ie: System.map-2.4.18-4GB what tells the kernel to look for the correct one? -- S.Toms - smotrs at mindspring.com - www.mindspring.com/~smotrs SuSE Linux v7.2+ - Kernel 2.4.16-4GB If at first you don't succeed, redefine success.
On Thursday 07 March 2002 06.11, S.Toms wrote:
Stupid question, but what exactly tells the kernel to use which System.map? I notice the kernels supplied by SuSE are named like this, System.map-2.4.16-4GB but if I compile my own it typically gets created as just System.map. Now if I wanted to use the same nameing to keep track of them, ie: System.map-2.4.18-4GB what tells the kernel to look for the correct one?
The kernel doesn't look at the map at all. It is used to get human readable names in crash output (see ksymoops). But I believe the default for ksymoops is to look at System.map-<kernel version>, but you can change that with -m mapname //Anders
Anders is right that the kernel itself doesn't actually look at System.map. Even more important than ksymoops, though, is the «ps» program, which also looks at System.map. What you care about for naming the System.map file is the output of «uname -r». You'll almost certainly have «uname -r» for your self-compiled 2.4.18 kernel give «2.4.18», so you'll call the file «/boot/System.map-2.4.18». The string UTS_VERSION in include/linux/version.h determines what version information uname -r will give for the kernel. So, if you're compiling a different version of the 2.4.18 kernel, you could just edit include/linux/version.h to call your hacked kernel '2.4.18-Anders1'. «ps» decides which System.map file to use based on the search path: $PS_SYSTEM_MAP /boot/System.map-`uname -r` /boot/System.map /lib/modules/`uname -r`/System.map /usr/src/linux/System.map /System.map (This is described in the ps(1) manual page). That was probably a lot more detail than you cared to know! --Steve Augart Anders Johansson wrote:
On Thursday 07 March 2002 06.11, S.Toms wrote:
Stupid question, but what exactly tells the kernel to use which System.map? I notice the kernels supplied by SuSE are named like this, System.map-2.4.16-4GB but if I compile my own it typically gets created as just System.map. Now if I wanted to use the same nameing to keep track of them, ie: System.map-2.4.18-4GB what tells the kernel to look for the correct one?
The kernel doesn't look at the map at all. It is used to get human readable names in crash output (see ksymoops).
But I believe the default for ksymoops is to look at System.map-<kernel version>, but you can change that with -m mapname
//Anders
On Thu, 07 Mar 2002 01:18:50 -0800
Steven Augart
version information uname -r will give for the kernel. So, if you're compiling a different version of the 2.4.18 kernel, you could just edit include/linux/version.h to call your hacked kernel '2.4.18-Anders1'.
The most logical thing to do is just name your System.map to match the kernel name. Then edit your /etc/rc.d/syslog script to call the matched name sleep 1 startproc ${BINDIR}/klogd -k "/boot/System.map-$(/bin/uname -r)" -c $KERNEL_LOGLEVEL || return=$rc_failed echo -e "$return" So if your make a kernel 2.4.18-number1 name the created System.map to /boot/System.map-2.4.18-number1 and your kernels and System.maps will always match up. -- $|=1;while(1){print pack("h*",'75861647f302d4560275f6272797f3');sleep(1); for(1..16){for(8,32,8,7){print chr($_);}select(undef,undef,undef,.05);}}
On Thu, 7 Mar 2002, zentara wrote:
z> On Thu, 07 Mar 2002 01:18:50 -0800
z> Steven Augart
On Thu, 7 Mar 2002, Steven Augart wrote: sa> Anders is right that the kernel itself doesn't actually sa> look at System.map. Even more important than ksymoops, though, sa> is the �ps� program, which also looks at System.map. sa> sa> What you care about for naming the System.map file is the sa> output of �uname -r�. You'll almost certainly have �uname -r� for sa> your self-compiled 2.4.18 kernel give �2.4.18�, so you'll call the file sa> �/boot/System.map-2.4.18�. sa> Actually, I have a routine that does the compilation of the kernel, modules, installation, lilo configuration, nameing, etc.. so the kernel files are actually being named vmlinuz-2.4.18-4GB, System.map-2.4.18-4GB, initrd.2.4.18-4GB and /lib/modules/modules-2.4.18-4GB all within the routine. sa> The string UTS_VERSION in include/linux/version.h determines what sa> version information uname -r will give for the kernel. So, if you're sa> compiling a different version of the 2.4.18 kernel, you could just edit sa> include/linux/version.h to call your hacked kernel '2.4.18-Anders1'. sa> Right, but I'm not actually trying to call the kernel something it's not, I want it to be called what ever it's supposed to based on the configuration (.config) file. sa> �ps� decides which System.map file to use based on the search path: sa> $PS_SYSTEM_MAP sa> /boot/System.map-`uname -r` sa> /boot/System.map sa> /lib/modules/`uname -r`/System.map sa> /usr/src/linux/System.map sa> /System.map sa> (This is described in the ps(1) manual page). sa> sa> That was probably a lot more detail than you cared to know! sa> Actually, you can never have too much information, that's how it tends to stick and be remembered. As for the information you gave for PS_SYSTEM_MAP, that's information I didn't know. :) sa> --Steve Augart sa> sa> Anders Johansson wrote: sa> > On Thursday 07 March 2002 06.11, S.Toms wrote: sa> > sa> >> Stupid question, but what exactly tells the kernel to use which sa> >>System.map? I notice the kernels supplied by SuSE are named like this, sa> >>System.map-2.4.16-4GB but if I compile my own it typically gets created as sa> >>just System.map. Now if I wanted to use the same nameing to keep track of sa> >>them, ie: System.map-2.4.18-4GB what tells the kernel to look for the sa> >>correct one? sa> >> sa> > sa> > The kernel doesn't look at the map at all. It is used to get human readable sa> > names in crash output (see ksymoops). sa> > sa> > But I believe the default for ksymoops is to look at System.map-<kernel sa> > version>, but you can change that with -m mapname sa> > sa> > //Anders sa> > sa> > sa> sa> -- S.Toms - smotrs at mindspring.com - www.mindspring.com/~smotrs SuSE Linux v7.2+ - Kernel 2.4.16-4GB If you've seen one redwood, you've seen them all. -- Ronald Reagan
S.Toms wrote:
On Thu, 7 Mar 2002, Steven Augart wrote:
Actually, I have a routine that does the compilation of the kernel, modules, installation, lilo configuration, nameing, etc.. so the kernel files are actually being named vmlinuz-2.4.18-4GB, System.map-2.4.18-4GB, initrd.2.4.18-4GB and /lib/modules/modules-2.4.18-4GB all within the routine.
Does this mean that you're happy with the setup you have now? I assume your original question, which I'm citing below, was just for personal information, or were you planning to do something with it?
Stupid question, but what exactly tells the kernel to use which System.map? I notice the kernels supplied by SuSE are named like this, System.map-2.4.16-4GB but if I compile my own it typically gets created as just System.map. Now if I wanted to use the same nameing to keep track of them, ie: System.map-2.4.18-4GB what tells the kernel to look for the correct one?
sa> The string UTS_VERSION in include/linux/version.h determines what sa> version information uname -r will give for the kernel. So, if you're sa> compiling a different version of the 2.4.18 kernel, you could just edit sa> include/linux/version.h to call your hacked kernel '2.4.18-Anders1'. sa>
Right, but I'm not actually trying to call the kernel something it's not, I want it to be called what ever it's supposed to based on the configuration (.config) file.
I assume this is a typo and you understand that the kernel's name is not set in the .config file at all. It's determined by whatever UTS_VERSION was in include/linux/version.h at the time you compiled the kernel. That is probably why SuSE includes the version.h file in /boot along with the .config and autoconf.h, so that you can recreate the exact kernel if you want to. More importantly here is that there is no Platonic ideal name for a kernel. All the name does is get used to match the modules with the kernel and to match the System.map file with the kernel. It's entirely for human convenience. I personally would actually strongly recommend modifying include/linux/version.h after even patching the kernel, just to help me keep it straight. And you'll have to modify it if you want to have multiple variants of the same kernel revision available (perhaps compiled with different options?) so that you can have appropriate modules and System.map files available for each variant.
sa> That was probably a lot more detail than you cared to know!
Actually, you can never have too much information, that's how it tends to stick and be remembered. As for the information you gave for PS_SYSTEM_MAP, that's information I didn't know. [:)]
To be honest, I didn't either until I looked at the ps manual page :). --Steve Augart
On Saturday 09 March 2002 11.44, Steven Augart wrote:
I assume this is a typo and you understand that the kernel's name is not set in the .config file at all. It's determined by whatever UTS_VERSION was in include/linux/version.h at the time you compiled the kernel.
The version.h file is created by "make dep" from info in the Makefile (look at the very top. Setting EXTRAVERSION to -foo gives you a version name 2.4.18-foo-4GB, for instance) //Anders
On Sat, 9 Mar 2002, Anders Johansson wrote: aj> On Saturday 09 March 2002 11.44, Steven Augart wrote: aj> > I assume this is a typo and you understand that the kernel's name is not aj> > set in the .config file at all. It's determined by whatever UTS_VERSION aj> > was in include/linux/version.h at the time you compiled the kernel. aj> aj> The version.h file is created by "make dep" from info in the Makefile (look at aj> the very top. Setting EXTRAVERSION to -foo gives you a version name aj> 2.4.18-foo-4GB, for instance) aj> Correct, the Makefile also grabs the HIGHMEMVERSION and SMPVERSION from settings derived from the .config file and appends them as well on line 94 of the Makefile. aj> //Anders aj> aj> -- S.Toms - smotrs at mindspring.com - www.mindspring.com/~smotrs SuSE Linux v7.2+ - Kernel 2.4.16-4GB Good day to let down old friends who need help.
On Sat, 9 Mar 2002, Steven Augart wrote: sa> S.Toms wrote: sa> > On Thu, 7 Mar 2002, Steven Augart wrote: sa> sa> sa> > Actually, I have a routine that does the compilation of the kernel, sa> > modules, installation, lilo configuration, nameing, etc.. so the kernel sa> > files are actually being named vmlinuz-2.4.18-4GB, System.map-2.4.18-4GB, sa> > initrd.2.4.18-4GB and /lib/modules/modules-2.4.18-4GB all within the sa> > routine. sa> sa> Does this mean that you're happy with the setup you have now? sa> I assume your original question, which I'm citing below, was just for sa> personal information, or were you planning to do something with it? sa> Pretty much for personal information. I mentioned in a following post that which as a follow up to zentara's that what I was looking for was the syslog file and the modification within it where it pertains to klogd. This was merly for convenience and wasn't because something was wrong or required. :) sa> > Stupid question, but what exactly tells the kernel to use which sa> > System.map? I notice the kernels supplied by SuSE are named like this, sa> > System.map-2.4.16-4GB but if I compile my own it typically gets created as sa> > just System.map. Now if I wanted to use the same nameing to keep track of sa> > them, ie: System.map-2.4.18-4GB what tells the kernel to look for the sa> > correct one? sa> sa> sa> > sa> The string UTS_VERSION in include/linux/version.h determines what sa> > sa> version information uname -r will give for the kernel. So, if you're sa> > sa> compiling a different version of the 2.4.18 kernel, you could just edit sa> > sa> include/linux/version.h to call your hacked kernel '2.4.18-Anders1'. sa> > sa> sa> > sa> > Right, but I'm not actually trying to call the kernel something it's sa> > not, I want it to be called what ever it's supposed to based on the sa> > configuration (.config) file. sa> sa> I assume this is a typo and you understand that the kernel's name is not sa> set in the .config file at all. It's determined by whatever UTS_VERSION sa> was in include/linux/version.h at the time you compiled the kernel. sa> Right, it gets the version from the version.h file, but parts of how you compile are appended to the line which calls out the version, ie: #define UTS_RELEASE "2.4.18-4GB" if you set certain settings within the .config file that pertain to the highmem or multiprocessing you'll get the 4GB, 64GB or SMP attached to the version, otherwise it will stay as just the following #define UTS_RELEASE "2.4.18" that is unless you physically modify it by changing it to your own nameing convention. sa> That is probably why SuSE includes the version.h file in /boot sa> along with the .config and autoconf.h, so that you can recreate sa> the exact kernel if you want to. sa> Which makes it real easy if you manage to screw things up without making back ups of them. :) sa> More importantly here is that there is no Platonic ideal name for sa> a kernel. All the name does is get used to match the modules with sa> the kernel and to match the System.map file with the kernel. sa> It's entirely for human convenience. I personally would actually sa> strongly recommend modifying include/linux/version.h after even sa> patching the kernel, just to help me keep it straight. And you'll sa> have to modify it if you want to have multiple variants of the sa> same kernel revision available (perhaps compiled with different sa> options?) so that you can have appropriate modules and System.map sa> files available for each variant. sa> sa> sa> > sa> That was probably a lot more detail than you cared to know! sa> sa> > Actually, you can never have too much information, that's how it tends sa> > to stick and be remembered. As for the information you gave for sa> > PS_SYSTEM_MAP, that's information I didn't know. [:)] sa> sa> To be honest, I didn't either until I looked at the ps manual page :). sa> sa> --Steve Augart sa> sa> sa> sa> -- S.Toms - smotrs at mindspring.com - www.mindspring.com/~smotrs SuSE Linux v7.2+ - Kernel 2.4.16-4GB If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro
participants (4)
-
Anders Johansson
-
S.Toms
-
Steven Augart
-
zentara