The assembler shouldn't be required either. Perhaps binutils could
ship with a proper tool. That would solve any portability problems.
(portability? all ports must use ELF AFAIK, for exception support)
>>> You mean pack System.map on the end of the zImage perhaps as a
>>> second gzip file ?
>>
>> That would be fine, as long as it can show up as /proc/System.map.gz
>> or become part of /proc/ksyms. It would be best to have separate
>
> ugh. "Please throw 150K of symbols into my memory image".
> I think not.
I think so! FreeBSD, AIX, Digital Unix, and Solaris all do this.
It is a small price to pay for reliable name resolution. It's not
150 kB either. In uncompressed binary format, it is about 80kB for
2.1.102. With compression, it is only 44 kB.
I used to be bothered by increases in kernel size too, but now I
realize that there is only one goal that matters: long-term, size
increases must be supported by Moore's Law. The proportion of memory
used by the kernel keeps shrinking as the years go by. I'm quite
sorry I ever complained about /dev/random being too big, since it is
insignificant in 1998. The rest of the unix world is running 8 MB
and 16 MB kernels now.
This would be good for oops reports too. There should never be any
worry that the wrong System.map file was used to resolve the symbols.
There are lots of Linux users that have trouble producing a good
oops report, and ksymoops doesn't help very much.
> If its packed into the zImage file you can pull them out
What about network boot?
> and if they are MD5'd and the MD5 signature is in the kernel
> you can even verify they match
That would help, but it is better to really solve the problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu