kernel/printk.c has this abomination.
/* Keep together for sysctl support */
int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
sysctl assumes that the 4 variables occupy contiguous storage. They
don't on ia64, console_loglevel is separate from the other variables.
echo 6 4 1 7 > /proc/sys/kernel/printk
on ia64 overwrites console_loglevel and the next 3 integers, whatever
they happen to be. On 2.4.12 it corrupts console_sem, other ia64
kernels will corrupt different data.
Does anybody fancy a small project to clean up these variables? They
need to become an integer array (say console_printk) containing 4
elements, which is what sysctl assumes. All references to these fields
have to be changed to refer to the corresponding array element. That
should be as simple as
#define console_loglevel (console_printk[0])
in kernel.h, as long as no other files declare console_loglevel or the
other variables. Alas at least two other files declare console_loglevel,
they need to be fixed to use the common declaration. I have not
checked the other console_xxx variables for extra declarations.
arch/parisc/kernel/traps.c: extern int console_loglevel;
arch/i386/mm/fault.c:extern int console_loglevel;
Keith Owens wrote:
> kernel/printk.c has this abomination.
>
> /* Keep together for sysctl support */
> int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
> int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
> int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
> int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
>
> sysctl assumes that the 4 variables occupy contiguous storage. They
> don't on ia64, console_loglevel is separate from the other variables.
>
> echo 6 4 1 7 > /proc/sys/kernel/printk
>
> on ia64 overwrites console_loglevel and the next 3 integers, whatever
> they happen to be. On 2.4.12 it corrupts console_sem, other ia64
> kernels will corrupt different data.
>
> Does anybody fancy a small project to clean up these variables?
I would like to give it a try. Seems like a good little project for one
who is trying to learn his way around the kernel :) It will probably
take me a lot longer than one of the experienced kernel hackers and
would probably not be perfect on the first try, but I'm willing to
invest some time in it.
Best regards,
Jesper Juhl
On Wed, 17 Oct 2001 15:39:06 +0200,
Jesper Juhl <[email protected]> wrote:
>Keith Owens wrote:
>> kernel/printk.c has this abomination.
>> int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
>> int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
>> int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
>> int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
>> Does anybody fancy a small project to clean up these variables?
>
>I would like to give it a try. Seems like a good little project for one
>who is trying to learn his way around the kernel :)
Good, I was hoping for somebody who wanted to get started on the
kernel. It's all yours, unless somebody else does a patch first.
Ensure that you find all references to these variables and make them
all use the common #define, instead of random files declaring the
variables themselves. Check all architectures as well.
On Wed, 17 Oct 2001, Keith Owens wrote:
> kernel/printk.c has this abomination.
>
> /* Keep together for sysctl support */
> int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
> int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
> int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
> int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
>
> sysctl assumes that the 4 variables occupy contiguous storage. They
> don't on ia64, console_loglevel is separate from the other variables.
>
> echo 6 4 1 7 > /proc/sys/kernel/printk
>
> on ia64 overwrites console_loglevel and the next 3 integers, whatever
> they happen to be. On 2.4.12 it corrupts console_sem, other ia64
> kernels will corrupt different data.
>
> Does anybody fancy a small project to clean up these variables? They
> need to become an integer array (say console_printk) containing 4
> elements, which is what sysctl assumes. All references to these fields
> have to be changed to refer to the corresponding array element. That
> should be as simple as
This is not the only problem related to sysctl. We still have
{KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int)
in kernel/sysctl.c, with
kdev_t real_root_dev;
in init/main.c,
extern kdev_t real_root_dev;
in drivers/block/rd.c, and
typedef unsigned short kdev_t;
in <linux/kdev_t.h>. Kaboom on big endian boxes, escpecially if the alignment
rules are 2-bytes, like on m68k.
In the m68k tree we have (since ages) a patch to change real_root_dev to int
and add some casts. Patch available upon request.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Keith Owens wrote:
>
> kernel/printk.c has this abomination.
>
> /* Keep together for sysctl support */
> int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
> int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
> int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
> int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
>
> sysctl assumes that the 4 variables occupy contiguous storage. They
> don't on ia64, console_loglevel is separate from the other variables.
>
> echo 6 4 1 7 > /proc/sys/kernel/printk
>
> on ia64 overwrites console_loglevel and the next 3 integers, whatever
> they happen to be. On 2.4.12 it corrupts console_sem, other ia64
> kernels will corrupt different data.
>
> Does anybody fancy a small project to clean up these variables? They
> need to become an integer array (say console_printk) containing 4
> elements, which is what sysctl assumes. All references to these fields
> have to be changed to refer to the corresponding array element. That
> should be as simple as
Yep. I asked someone to clean this up about
3 weeks ago, and he said that he would do so, but....?
So Jesper or someone else should jump on it.
~Randy