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,
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.