On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Mike Galbraith wrote:
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel level
debugger and in real
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
Andrea Arcangeli wrote:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
Sorry, that does just one read, kgcc (old stable gcc) and also with
gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
I wrote the above not
Linus Torvalds wrote:
"volatile" should be equivalent to clobbering memory, although the gcc
manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
On Thu, 7 Sep 2000, Jamie Lokier wrote:
It's ok for the compiler to do that (given we don't know what "volatile"
means anyway :-). But it does have implications for spin_lock:
spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
Linus Torvalds wrote:
Change it to something like
__asm__("":"=r" (x):"0" (x));
and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory references
On Thu, 7 Sep 2000, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
Ingo Molnar wrote:
Your arguments are personal, not technical. [...]
no, my arguments are technical, but are simply focused towards the
conceptual (horizontal) development of Linux, not the vertical
development of Linux (drivers) and
On Thu, 7 Sep 2000, Franz Sirl wrote:
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Ok. That's all I wanted
Linus Torvalds wrote:
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That would be silly: an asm that just
wipes all memory would not be a very useful asm (or rather, it would have
just _one_ use: "execve()"). So "memory" really says
On Thu, 7 Sep 2000, Jamie Lokier wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
At 17:03 07.09.00, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the
Andrea Arcangeli wrote:
Said that if your compiler puts the read before the spin_lock without the
memory clobber, it is allowed to do that, and in such case you would proof
it was a real world bug (not just a "documentation" one).
Yes, it does.
Or maybe your testcase was a bit different
Andrea Arcangeli wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
On Thu, 7 Sep 2000, Jamie Lokier wrote:
Yes, it does.
Nice.
.ident "GCC: (GNU) 2.96 2724 (experimental)"
From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
Ingo,
I did read it. You have to understand, I'm not a young guy but an old
man, so it takes me longer to ponder and digest things -- not because
I'm slower, but becasue I'm older. I used to blindy charge at anything
when a red flag was waved in front of my face in my youth. As I got
older,
On Thu, 7 Sep 2000, Jamie Lokier wrote:
I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
.ident "GCC: (GNU)
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then
On Thu, 7 Sep 2000, Jeff V. Merkey wrote:
[...] so it takes me longer to ponder and digest things -- [...]
i'll quote a few 'digesting' comments of you:
- about the Linux networking code:
" [...] what a mess indeed. "
- about Linux itself:
" The lack of a Kernel Debugger and other basic
Jeff, please read Linus' mail for an explanation about the dangers of
kernel debuggers.
Ingo
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Ingo,
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver. It's not designed as a kernel
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
David Woodhouse wrote:
But how much work would it require to do so? If your theoretical vendor of
closed-source compiler backends were to believe that a shared lib of the
GCC frontend would be legal, surely they'd just make it shared themselves,
then use it as such? It's hardly a effective
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the memory
I loose track at times Stephen -- sorry. I was talking about kgdb with
this statement.
:-)
Jeff
"Stephen C. Tweedie" wrote:
Hi,
On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run
Hi,
On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
KDB is a user mode debugger designed to debug user space apps that's
been hacked to run with a driver.
Absolutely not true. You're probably thinking about kgdb, the gdb
stub for remote kernel source level debugging.
kdb
This applies to any recent kernel. Changes :
-Forwarding between high speed interfaces
+NIC Hardware throttling for high speed interfaces
The original is confusing with the previous option which is "Fast
switching (read help!)", one might infer similar.
-d
--
"The difference between
"David S. Miller" wrote:
Date:Thu, 07 Sep 2000 14:36:02 -0700
From: Jun Sun [EMAIL PROTECTED]
Here is a small patch which is needed on non-i386 platforms.
The layout of this structure is exported to userspace
applications, thus you cannot simply just change the
type
Date: Thu, 07 Sep 2000 17:35:22 -0700
From: Jun Sun [EMAIL PROTECTED]
Do we know exactly what userland apps/libs use ifmap? Maybe the
damage is not so bad, so that we can fix this problem without
making it look worse.
It's a well established fixed kernel API, any app whatsoever
"David S. Miller" wrote:
Date: Thu, 07 Sep 2000 17:35:22 -0700
From: Jun Sun [EMAIL PROTECTED]
Do we know exactly what userland apps/libs use ifmap? Maybe the
damage is not so bad, so that we can fix this problem without
making it look worse.
It's a well established
On Thu, Aug 17, 2000 at 12:36:51PM -0700, Kanoj Sarcar wrote:
Except for the x86 36bit abortion do we need a long long paddr_t on any
32bit platform ?
Sparc32, mips32...
Not for Indys on mips32. Is there a mips32 port on another machine
(currently in Linux, or port ongoing)
On Thu, Aug 17, 2000 at 12:41:52PM -0700, David S. Miller wrote:
ISA is a dead hardware technology and therefore how it works is pretty
much fixed in stone.
Perhaps some older MIPS machines supporting ISA could benefit from
an API similar to the PCI dma stuff, as Alan mentioned. But that
401 - 431 of 431 matches
Mail list logo
