Um? Huh? This seems like mumbo-jumbo to me. With the exception of those
parts of the kernel that actually manipulate the hardware as hardware, --
which is a surprisingly small part of the kernel, even of the parts of the
kernel that look like what they do is manipulate the hardware as hardware --
code executing in a kernel behaves exactly like code executing in any other
part of the system. - It is, in fact, often not possible to tell outside the
processor control registers, whether the executing code is running in 'priv'
mode or not, so the same code will show the same bus trace in or out of the
kernel.
In fact, if the underlying hardware architecture has an appropriate
separation between memory addressability and memory accessability mechanisms
within address translation, and a reasonable i/o architecture, only a very
tiny fraction of 'the kernel' needs to execute with any different privileges
than any other application. (I got it down to page table entry management
and trap/interrupt entry and exit in one kernel, but that was on a *very*
nice hardware architecture.)
Marty (who *has* used logic analysers to debug new CPU designs and other OS
problems.)
-----Original Message-----
From: Jeff V. Merkey [mailto:jmerkey@timpanogas.org]
Sent: Sunday, October 15, 2000 11:20 PM
To: erayo@cs.bilkent.edu.tr
Cc: J . A . Magallon; linux-kernel@vger.kernel.org
Subject: Re: [Criticism] On the discussion about C++ modules
Not meant to offend, but it's obvious you are not grasping hardware
optimization issues relative to kernel development and performance. I
would recommend getting your hands on a bus analyzer, and testing out
some of your theories, and explore for yourself relative to these issues
with some hard numbers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:08 EST