Dear Mr. Miller,
dear listmembers,
I have been gently advised to send this message to the list directly, so here you go. Sorry for the bounces. This refers to replacing the unsigned long against unsigned int in struct kernel_sym in linux/include/linux/module.h:
--- linux/include/linux/module.h 2004-12-15 08:34:44.000000000 +0100
+++ linux/include/linux/module.h 2004-12-15 08:45:32.000000000 +0100
@@ -31,7 +31,11 @@
/* Used by get_kernel_syms, which is obsolete. */
struct kernel_sym
{
- unsigned long value;
+#ifdef __ARCH_SPARC64_ATOMIC__
+ unsigned int value;
+#else
+ unsigned long value;
+#endif
char name[60]; /* should have been 64-sizeof(long); oh well */
};
For your explanation, the posting below I had had sent initially in 2004 - quite some time ago. See below. As nobody reacted and the list says: be patient, I thought it might be a good idea to send this to the kernel mailing list directly.
Sorry, maybe I sent to debian sparc instead of sparclinux, and I did not make a CC to sparclinux right now. Here you see two debug - messages "Size of table: 1843, what is too much to work, because SPARC 64 kernel "off stock" can only do 1820 for Size of table.
Dec 13 09:35:10 oekalux09 syslogd 1.4.1#16: restart.
Dec 13 09:35:10 oekalux09 kernel: klogd 1.4.1#16, log source = /proc/kmsg started.
Dec 13 09:35:10 oekalux09 kernel: Inspecting /boot/System.map-2.4.26-SMP
Dec 13 09:35:11 oekalux09 kernel: Loaded 14411 symbols from /boot/System.map-2.4.26-SMP.
Dec 13 09:35:11 oekalux09 kernel: Symbols match kernel version 2.4.26.
**** Dec 13 09:35:11 oekalux09 kernel: Loading kernel module symbols - Size of table: 1843 Sizeof alloc: >>117952 /* debugging */
**** Dec 13 09:35:11 oekalux09 kernel: We use __GLIBC__ for klogd /* debugging */
>>>> Dec 13 09:35:11 oekalux09 kernel: Error reading kernel symbols -
>>>> Cannot allocate memory
Dec 13 09:35:11 oekalux09 kernel: Errno was: -1
Dec 13 09:35:11 oekalux09 kernel: PROMLIB: Sun IEEE Boot Prom 3.23.1 1999/07/16 12:08
Dec 13 09:35:12 oekalux09 kernel: Linux version 2.4.26-SMP (root@oekalux09) (gcc-Version 3.3.4 (Debian 1:3.3.4-13)) #1 SMP Mo Dez 13 09:01:5
And the root cause is, (citing myself):
> What I found is that the allocation works up to 1820 elements of the
> size 72 Bytes, however, we would need a tiny little more (1843 in my
> case, please take a look into the attachement).
and the solution is: use an unsigned int rather than an unsigned long for "value" in struct kernel_sym. We get usually 60 Bytes from char name[] and another 4 Byte from unsigned long value on i386. However, in kernel space sizeof (unsigned long) gives 8 for sparc64, thereby enlarging sizeof(kernel_sym) to 68. We have to be word aligned, so we end up with 72Byte per struct kernel_sym rather than 64Byte per struct kernel_sym on i386. This in turn allows 2^17/72 symbols to be read in contrast to 2^17/64 symbols to be read. Therefore on sparc64 one does not get more than 1820 symbols in contrast to 2048 symbols on i386.
the only possible cause IMHO is the fact that sizeof (unsgned long) in kernel space is 8 and not 4, because the array of char in struct kernel_sym cannot cause this.
Using my suggested patch I get (today since then ...) no error, no warning:
Aug 15 06:48:54 oekalux08 syslogd 1.4.1: restart.
Aug 15 06:48:55 oekalux08 in.identd[634]: started
Aug 15 06:48:59 oekalux08 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Aug 15 06:48:59 oekalux08 kernel: Inspecting /boot/System.map-2.4.33-SMP
Aug 15 06:49:00 oekalux08 kernel: Loaded 14439 symbols from /boot/System.map-2.4.33-SMP.
Aug 15 06:49:00 oekalux08 kernel: Symbols match kernel version 2.4.33.
Aug 15 06:49:00 oekalux08 kernel: Loaded 241 symbols from 11 modules.
Aug 15 06:49:00 oekalux08 kernel: ip_tables: (C) 2000-2002 Netfilter core team
Aug 15 06:49:00 oekalux08 kernel: ip_conntrack version 2.1 (4015 buckets, 32120 max) - 416 bytes per conntrack
*******
I readily mentionend back in 2004 that I do not think my using this #define was very smart, I think that the "kernel gurus" out there can do much better here.
I cannot think of any reason value should be larger than 2^32, but maybe I am wrong. AFAIK there is no way to make kmalloc() provide more than 2^17 Byte, but maybe I am wrong here, too.
If you say this cannot work: please be more specific. If you need even debug output / a patch showing exactly this, I can provide. As a matter of fact: it works. If the reason why it works differs from my explanation I would highly appreciate to be told why.
Just saying: "I cannot see why this should work" is hardly of any help for understanding things.
Take care
Dieter Jurzitza
--
________________________________________________
HARMAN BECKER AUTOMOTIVE SYSTEMS
Dr.-Ing. Dieter Jurzitza
Manager Hardware Systems
System Development
Industriegebiet Ittersbach
Becker-Göring Str. 16
D-76307 Karlsbad / Germany
Phone: +49 (0)7248 71-1577
Fax: +49 (0)7248 71-1216
eMail: DJurzitza@xxxxxxxxxxxxxxxx
Internet: http://www.becker.de
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
