On Fri, Feb 23, 2007 at 09:18:59AM +0100, Kevin D. Kissell wrote: > One thing about the current, system-call based interface that is kind-of > cool, and different from both what you propose and what was described > as being implemented for ARM, is that Ralf's scheme is per-thread. > I don't know if that power really outweighs the ease-of-use aspect > of being able to manipuate it from the shell command line, but it's > not something to throw away lightly. I have no issues with moving > the log data, should it be resurrected, from syslog to /sys/kernel/whatever, > though. There are two different things here that need to be sorted out - but for years nobody noticed so this never really did show up on the radar: o sysmips is really a compatibility interface meant to support software that did originate on IRIX, RISC/os and maybe even MIPS/os. But sysmips(MIPS_FIXADE,...) is a new operation that I came up with for Linux. So I'd like this interface to die. o sysmips(MIPS_FIXADE, ...) does control only the fixup operation of the kernel on a per thread base. Loggin is not controlled by it; that was available in the dark past only as a compile time option. o The MIPS_FIXADE setting is inherited across clone and fork. I could almost bet no software relying on this feature is actually explicitly enabling it. Maybe the default should be off to make programmers aware of this kind of issue in their code? o The MIPS_FIXADE setting is valid for both kernel and user mode. So if for example the TCP stack is taking an unaligned exception to process an incoming packet, it will look at the setting of the process that just happens to be running on the CPU. o I think it would be handy to have a method to externally control the MIPS_FIXADE setting of a process. o Logging unaligned accesses is a dangerous thing; it can easily reach a DoS-like volume. Ralf
