** On Sep 19, Marty Fouts scribbled:
> Gene did the instruction set architecture along with some others. I think he
> was also involved in the i/o architecture.
Marty, could you _please_ stop posting to this thread on lkml and _PLEASE_
learn how to snip messages and _DON'T_ quote everything you
On Mon, 18 Sep 2000, Marty Fouts wrote:
> It contains a wee bit of wisdom.
be not wise in thine own eyes, yea, let other man praise thee. ;)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
On Mon, 18 Sep 2000, Marty Fouts wrote:
It contains a wee bit of wisdom.
be not wise in thine own eyes, yea, let other man praise thee. ;)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
** On Sep 19, Marty Fouts scribbled:
Gene did the instruction set architecture along with some others. I think he
was also involved in the i/o architecture.
Marty, could you _please_ stop posting to this thread on lkml and _PLEASE_
learn how to snip messages and _DON'T_ quote everything you
Please kill this thread.
Linus has stated he does not want a kernel debugger in the standard
kernel. As the maintainer of kdb I accept that decision and will
maintain kdb outside the kernel. Any other discussion is just noise.
-
To unsubscribe from this list: send the line "unsubscribe
]
Subject: RE: Availability of kdb
Gene Amdahl I think...
On Mon, 18 Sep 2000, Marty Fouts wrote:
> I think that more people quote Brooks than have read him and that more
> people know him from the Mythical Man Month than from the POO.
>
> He wasn't, by the way, the principle architect o
TED]]
> Sent: Monday, September 18, 2000 3:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Availability of kdb
>
> Marty Fouts writes:
> > Here's another piece of free advice, worth less than you paid for it: in
> 25
> > years, only the computer history trivia geeks are going
of MMM is Brooks'
apology to Gries about being wrong about information hiding.
-Original Message-
From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 3:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Availability of kdb
Marty Fouts writes:
> Here's another pi
AM
To: Marty Fouts
Cc: 'Larry McVoy'; 'Linus Torvalds'; Oliver Xymoron; Daniel Phillips; Kernel
Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied
environments
> than nearly anyone here,
"J. Dow" wrote:
>
> Jeff et al who might prefer a kernel debugger,
>
> One should note that when a person or critter is backed into a corner
> and pressured hard enough that he makes an "over my dead body"
> level statement more pressure is likely to solidify the position rather
> than change
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
> Marty,
>
> I think they said they could care less about kernel debuggers. Just go
> write one, use Keith's or ours or whatever, and do what you want with
> your Linux development -- Linus doesn't seem to care if you just make a
> fork of Linux or
On Sun, Sep 17, 2000 at 08:40:33PM -0700, Larry McVoy wrote:
> On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> I'm sort of in the middle. I know BitKeeper very well, and it's actually
> a larger wad of code than the kernel if you toss out the device drivers.
> About the only thing
Marty,
I think they said they could care less about kernel debuggers. Just go
write one, use Keith's or ours or whatever, and do what you want with
your Linux development -- Linus doesn't seem to care if you just make a
fork of Linux or someone else does with a debugger for your projects.
Marty Fouts writes:
> Here's another piece of free advice, worth less than you paid for it: in 25
> years, only the computer history trivia geeks are going to remember you,
> just as only a very small handful of us now remember who wrote OS/360.
You mean like Fred Brooks who managed the
On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied environments
> than nearly anyone here, having brought up a new OS, compiler, and CPU
yea yea yea, if you are so good then you should be concentrating on giving
your goodness and wisdom and
17, 2000 10:40 PM
To: Marty Fouts
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Availability of kdb
From: Marty Fouts <[EMAIL PROTECTED]>
Date:Sun, 17 Sep 2000 22:42:22 -0700
I've pr
On Sun, 17 Sep 2000, Marty Fouts wrote:
I've probably debugged more operating systems under more varied environments
than nearly anyone here, having brought up a new OS, compiler, and CPU
yea yea yea, if you are so good then you should be concentrating on giving
your goodness and wisdom and
Marty Fouts writes:
Here's another piece of free advice, worth less than you paid for it: in 25
years, only the computer history trivia geeks are going to remember you,
just as only a very small handful of us now remember who wrote OS/360.
You mean like Fred Brooks who managed the development
AM
To: Marty Fouts
Cc: 'Larry McVoy'; 'Linus Torvalds'; Oliver Xymoron; Daniel Phillips; Kernel
Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
I've probably debugged more operating systems under more varied
environments
than nearly anyone here, having
]
Subject: Re: Availability of kdb
Marty Fouts writes:
Here's another piece of free advice, worth less than you paid for it: in
25
years, only the computer history trivia geeks are going to remember you,
just as only a very small handful of us now remember who wrote OS/360.
You mean
]
Subject: RE: Availability of kdb
Gene Amdahl I think...
On Mon, 18 Sep 2000, Marty Fouts wrote:
I think that more people quote Brooks than have read him and that more
people know him from the Mythical Man Month than from the POO.
He wasn't, by the way, the principle architect of OS/360; he
Please kill this thread.
Linus has stated he does not want a kernel debugger in the standard
kernel. As the maintainer of kdb I accept that decision and will
maintain kdb outside the kernel. Any other discussion is just noise.
-
To unsubscribe from this list: send the line "unsubscribe
Marty,
I think they said they could care less about kernel debuggers. Just go
write one, use Keith's or ours or whatever, and do what you want with
your Linux development -- Linus doesn't seem to care if you just make a
fork of Linux or someone else does with a debugger for your projects.
On Sun, Sep 17, 2000 at 08:40:33PM -0700, Larry McVoy wrote:
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
I'm sort of in the middle. I know BitKeeper very well, and it's actually
a larger wad of code than the kernel if you toss out the device drivers.
About the only thing I
From: "Jeff V. Merkey" [EMAIL PROTECTED]
Marty,
I think they said they could care less about kernel debuggers. Just go
write one, use Keith's or ours or whatever, and do what you want with
your Linux development -- Linus doesn't seem to care if you just make a
fork of Linux or someone
"J. Dow" wrote:
Jeff et al who might prefer a kernel debugger,
One should note that when a person or critter is backed into a corner
and pressured hard enough that he makes an "over my dead body"
level statement more pressure is likely to solidify the position rather
than change it. In
17, 2000 10:40 PM
To: Marty Fouts
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Availability of kdb
From: Marty Fouts [EMAIL PROTECTED]
Date:Sun, 17 Sep 2000 22:42:22 -0700
I've probably debugged
From: Marty Fouts <[EMAIL PROTECTED]>
Date:Sun, 17 Sep 2000 22:42:22 -0700
I've probably debugged more operating systems under more varied
environments than nearly anyone here
Which one of them was %100 distributed where no two of the developers
were in the same building and
0 8:41 PM
To: Marty Fouts
Cc: 'Linus Torvalds'; Oliver Xymoron; Tigran Aivazian; Daniel Phillips;
Kernel Mailing List
Subject: Re: Availability of kdb
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user"
carp
er Xymoron; Tigran Aivazian; Daniel Phillips; Kernel Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
>
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it. And, frankly, if you wish to artificially limit your u
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user" carpentry
> to "hand tools only" you can actually do it fairly easily on PBS in the US.
> There used to be a program done by a guy who did everything by hand. I
>
Linus Torvalds wrote:
> On Sun, 17 Sep 2000, Marty Fouts wrote:
> >
> > Craftsmanship is in the way you approach what you do, not in the tools you
> > use to do it. And, frankly, if you wish to artificially limit your use of
> > tools, all you are doing is hobbling yourself.
>
> You know what?
On Sun, 17 Sep 2000, Marty Fouts wrote:
>
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it. And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.
You know what?
Start your own kernel (or split
Linus Torvalds wrote:
On Sun, 17 Sep 2000, Marty Fouts wrote:
Craftsmanship is in the way you approach what you do, not in the tools you
use to do it. And, frankly, if you wish to artificially limit your use of
tools, all you are doing is hobbling yourself.
You know what?
Start
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
Um, for what ever it is worth, if you want to compare "power user" carpentry
to "hand tools only" you can actually do it fairly easily on PBS in the US.
There used to be a program done by a guy who did everything by hand. I
loved
er Xymoron; Tigran Aivazian; Daniel Phillips; Kernel Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
Craftsmanship is in the way you approach what you do, not in the tools you
use to do it. And, frankly, if you wish to artificially limit your use of
t
From: Marty Fouts [EMAIL PROTECTED]
Date:Sun, 17 Sep 2000 22:42:22 -0700
I've probably debugged more operating systems under more varied
environments than nearly anyone here
Which one of them was %100 distributed where no two of the developers
were in the same building and
On Tue, 12 Sep 2000, Jeff V. Merkey wrote:
>
> Ted,
>
> I am looking at these sources as well. One thing I went back and looked
> at was related to a comment from Mike G. I believe regarding drivers
> conflicts with int 0x13 requests potentially hosing the IDE driver. In
Hmm.. must be a
Ted,
I am looking at these sources as well. One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver. In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a
Date: Mon, 11 Sep 2000 17:51:20 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
of software that can quickly get out of sync if it's maintained
separately from the tree -- the speed at which changes occur in Linux
would render it a very difficult project
Date: Mon, 11 Sep 2000 17:51:20 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux is
Ted,
I am looking at these sources as well. One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver. In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a
On Tue, 12 Sep 2000, Jeff V. Merkey wrote:
Ted,
I am looking at these sources as well. One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver. In
Hmm.. must be a different
Keith Owens wrote:
>
> On Mon, 11 Sep 2000 16:19:14 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Who pays you?
>
> I used to work on kdb in my own time, for free. Then I joined SGI and
> now I get paid to work on it. If I left SGI I would continue to work
> on kdb, the original
The code is at vger.timpanogas.org. If you want to review it, it's
there. We are posting another MANOS kernel with full VM end of the
month. The version Darren and I are hacking on now has the debugger
broken out as a module as a prelude to put it in Linux. I am working on
your kdb stubs in
On Mon, 11 Sep 2000 16:24:32 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Keith,
>
>If you are volunteering to maintain the MANOS debugger after I hack it
>into Linux, then I accept. I'll give you an ftp and telnet account on
>vger.timpanogas.org and you can run with it.
How on earth
On Mon, 11 Sep 2000 16:19:14 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Who pays you?
I used to work on kdb in my own time, for free. Then I joined SGI and
now I get paid to work on it. If I left SGI I would continue to work
on kdb, the original kdb developer left SGI but still
Keith,
If you are volunteering to maintain the MANOS debugger after I hack it
into Linux, then I accept. I'll give you an ftp and telnet account on
vger.timpanogas.org and you can run with it.
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> Who pays you?
>
> Keith Owens wrote:
> >
> > On Mon, 11 Sep
Who pays you?
Keith Owens wrote:
>
> On Mon, 11 Sep 2000 09:46:15 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
> >of software that can quickly get out of sync if it's maintained
> >separately from the tree --
On Mon, 11 Sep 2000 09:46:15 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
>of software that can quickly get out of sync if it's maintained
>separately from the tree -- the speed at which changes occur in Linux
>would
On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Jeff V. Merkey wrote:
> > In NetWare, we didn't care if the page was touched or not since we
> > used our own bits in field bits 11-9 to store page specific stuff,
> > like whether the page was dirty or not.
>
> Linux does actually look at both bits,
On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Rik van Riel wrote:
> > The main difference between Linux and Netware here is the
> > fact that Linux has a real userland, which can touch the
> > pages on its own without going through the kernel.
> >
> > This causes "spontaneously" dirtied or accessed
Rik van Riel wrote:
> The main difference between Linux and Netware here is the
> fact that Linux has a real userland, which can touch the
> pages on its own without going through the kernel.
>
> This causes "spontaneously" dirtied or accessed pages,
> meaning that we really want to use the
One way of increasing signal to noise ratio (place in .procmailrc):
:0
* ^FROM.*jmerkey@timpanogas\.com
/dev/null
On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
> Now will you stop trying to incite pointless riots and allow those
[EMAIL PROTECTED] wrote:
> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?
>
> -ben
Ben,
Read the thread before
I'll give it some thought. Most of Linux has better paging than NetWare
already -- NetWare is pretty simple in this respect. THe process
mapping stuff in Netware (PCB's are mapped to recursively point to
themselves with a global brach table) is unique, but not as good as
what's in Linux.
:-)
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
> If you need to know if the page has been accessed, you can clear this
> bit when a page is first mapped, and when someone touches it, the
> hardware will set this bit. It set's it by doing a R/M/W operation on
We've set the accessed bit for a long
Jeff V. Merkey wrote:
> One of the best references that describes the bus transaction model for
> Intel in "plain english" is the Pentium Pro Processor System
> Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> ISBN: 0-201-47953-2. It explains a very good detail how the
Rik van Riel wrote:
> > The person writing and updating page table entries in NetWare
> > 4.1 was clearing the accessed bit in the PTE and did not know
> > that the processor would assert a hidden R/M/W operation and
> > assert a bus lock to set this bit everytime someone cleared it
> > -- it
Allright, You've convinced me. I'll do it. It will require consierable
support moving forward.
:-)
Jeff
Miles Lane wrote:
>
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> >
> >
> > "Theodore Y. Ts'o" wrote:
> >
> > >
> > > If you come up with robust, easy to patch source-code-level
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
>
> "Theodore Y. Ts'o" wrote:
>
> >
> > If you come up with robust, easy to patch source-code-level debugger for
> > Linux, some people will use it, and some people won't. If it's better
> > than kdb, eventually it'll displace kdb as the
> "A" == Alexander Viro <[EMAIL PROTECTED]> writes:
A> As for the "greater social good" (or world domination, for that
A> matter) - excuse me, but quite a few of us couldn't care
A> less.
Thanks for the comment, and please don't feel guilty about it, it is a
perfectly valid
Jamie,
I referenced a great book an an email to Rik Van Reil. It's got a great
explanation of this stuff.
:-)
Jeff
Jamie Lokier wrote:
>
> Jeff V. Merkey wrote:
> > This means it completely unnecessary to assert LOCK# for the unlock
> > case, since there are no ordering issues persay -
Rik,
One of the best references that describes the bus transaction model for
Intel in "plain english" is the Pentium Pro Processor System
Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
ISBN: 0-201-47953-2. It explains a very good detail how the cache
controllers and
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
> The person writing and updating page table entries in NetWare
> 4.1 was clearing the accessed bit in the PTE and did not know
> that the processor would assert a hidden R/M/W operation and
> assert a bus lock to set this bit everytime someone cleared
Jeff V. Merkey wrote:
> This means it completely unnecessary to assert LOCK# for the unlock
> case, since there are no ordering issues persay - the other processors
> are spinning on the lock already and cannot get through.
Yes I know I left out the context. Doesn't change what I'm about to
Jamie Lokier wrote:
>
> Jeff V. Merkey wrote:
> > The best info I know of is to get an analyser that plugs into the
> > processor socket (like an american arium) and enable branch trace
> > messaging to monitor the interaction between the processor and the cache
> > controllers. You get info
Lars Marowsky-Bree wrote:
> > I still don't see how processor traces will tell me what ordering
> > guarantees I can rely on across the range of processors.
>
> It will tell you when your assumptions were wrong.
Indeed. Like testing, but better.
-- Jamie
-
To unsubscribe from this list: send
On 2000-09-11T18:11:11,
Jamie Lokier <[EMAIL PROTECTED]> said:
> I still don't see how processor traces will tell me what ordering
> guarantees I can rely on across the range of processors.
It will tell you when your assumptions were wrong.
Sincerely,
Lars Marowsky-Brée <[EMAIL
Jamie,
I should have never brought this example up. The thread "spin_unlock()
optimization" that went on for three weeks with Intel and the whole
planet getting into the fray speaks for itself, and anyone wanting to
search the kernel archives can do so and for their own opinion. I won't
use a
Gary Lawrence Murphy wrote:
> The analogy to typing hex codes or toggling code at the console is
> also apt. Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I
> tend to debug intuitively based on my knowledge of
> > But in the end, maybe the rule to only use hand power makes sense. Not
> > because hand-power is _better_. But because it brings in the kind of
> > people who love to work with their hands, who love to _feel_ the wood with
> > their fingers, and because of that their holes are not always
On 11 Sep 2000, Gary Lawrence Murphy wrote:
> > "H" == Horst von Brand <[EMAIL PROTECTED]> writes:
>
> H> In the end, this is Linus' game. If you want to play, you'll
> H> have to pay the admission price he sets.
>
> Is it fair to ask about the purpose of Linux?
>
> The
> "H" == Horst von Brand <[EMAIL PROTECTED]> writes:
H> In the end, this is Linus' game. If you want to play, you'll
H> have to pay the admission price he sets.
Is it fair to ask about the purpose of Linux?
The purpose I most often hear talks about world domination and about
Jeff V. Merkey wrote:
> To cite a Linux specific example, let's take the issue with the memory
> write for a spin_unlock(). Linus seemed to have trouble grasping why
> a simple ' mov , 0' would work as opposed to a 'lock dec
> '
No logic analyser will tell you the subtleties of _why_ it works.
On Wed, 6 Sep 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Sep 2000, Marco Colombo wrote:
> >
> > As you said, the are two kinds of reactions. I don't understand why you
> > think that the presence of a debugger will *prevent* people from doing
> > the Right Thing and "think about problems
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
[ Jeff V. Merkey, super man ]
Huh. Once again, none of your facts is straight or correct:
>Famous double YY's of history:
>Good:
[...]
>Albert Einstein
--- cut ---
http://www.aip.org/history/einstein/einbrain.htm
Was Einstein's Brain Different?
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
>They are bad because they cost people money that could be spent more
>productively in other areas due to the lengthening of the development
You still miss the point.
Most kernel developers don't give a damn about money. If you're in
kernel
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
> Since Linus has rejected kdb there's every indication he will reject any other
> kernel debugger submissions -- also his right. I think my time would be better
> spent completing the merge of the Linux code base onto MANOS since moving the
> debugger
"Jeff V. Merkey" wrote:
> "David S. Miller" wrote:
>
> >Date:Sun, 10 Sep 2000 18:14:03 -0600
> >From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> >
> >Linus' apparently did not understand this, or he would have
> >immediately realized that double locking was always generating
"David S. Miller" wrote:
>Date:Sun, 10 Sep 2000 18:14:03 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>Linus' apparently did not understand this, or he would have
>immediately realized that double locking was always generating a
>second non-cacheable memory
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
Since Linus has rejected kdb there's every indication he will reject any other
kernel debugger submissions -- also his right. I think my time would be better
spent completing the merge of the Linux code base onto MANOS since moving the
debugger
On Wed, 6 Sep 2000, Linus Torvalds wrote:
On Wed, 6 Sep 2000, Marco Colombo wrote:
As you said, the are two kinds of reactions. I don't understand why you
think that the presence of a debugger will *prevent* people from doing
the Right Thing and "think about problems another way".
"H" == Horst von Brand [EMAIL PROTECTED] writes:
H In the end, this is Linus' game. If you want to play, you'll
H have to pay the admission price he sets.
Is it fair to ask about the purpose of Linux?
The purpose I most often hear talks about world domination and about
having the
On 11 Sep 2000, Gary Lawrence Murphy wrote:
"H" == Horst von Brand [EMAIL PROTECTED] writes:
H In the end, this is Linus' game. If you want to play, you'll
H have to pay the admission price he sets.
Is it fair to ask about the purpose of Linux?
The purpose I most often
But in the end, maybe the rule to only use hand power makes sense. Not
because hand-power is _better_. But because it brings in the kind of
people who love to work with their hands, who love to _feel_ the wood with
their fingers, and because of that their holes are not always perfectly
Gary Lawrence Murphy wrote:
The analogy to typing hex codes or toggling code at the console is
also apt. Unix ascended over Multix in no small part because of C,
which drew sneers from the trad programmer of the day. Personally, I
tend to debug intuitively based on my knowledge of code,
On 2000-09-11T18:11:11,
Jamie Lokier [EMAIL PROTECTED] said:
I still don't see how processor traces will tell me what ordering
guarantees I can rely on across the range of processors.
It will tell you when your assumptions were wrong.
Sincerely,
Lars Marowsky-Brée [EMAIL PROTECTED]
Lars Marowsky-Bree wrote:
I still don't see how processor traces will tell me what ordering
guarantees I can rely on across the range of processors.
It will tell you when your assumptions were wrong.
Indeed. Like testing, but better.
-- Jamie
-
To unsubscribe from this list: send the
Jamie Lokier wrote:
Jeff V. Merkey wrote:
The best info I know of is to get an analyser that plugs into the
processor socket (like an american arium) and enable branch trace
messaging to monitor the interaction between the processor and the cache
controllers. You get info that's
Jeff V. Merkey wrote:
This means it completely unnecessary to assert LOCK# for the unlock
case, since there are no ordering issues persay - the other processors
are spinning on the lock already and cannot get through.
Yes I know I left out the context. Doesn't change what I'm about to
say.
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
The person writing and updating page table entries in NetWare
4.1 was clearing the accessed bit in the PTE and did not know
that the processor would assert a hidden R/M/W operation and
assert a bus lock to set this bit everytime someone cleared it
Rik,
One of the best references that describes the bus transaction model for
Intel in "plain english" is the Pentium Pro Processor System
Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
ISBN: 0-201-47953-2. It explains a very good detail how the cache
controllers and
Jamie,
I referenced a great book an an email to Rik Van Reil. It's got a great
explanation of this stuff.
:-)
Jeff
Jamie Lokier wrote:
Jeff V. Merkey wrote:
This means it completely unnecessary to assert LOCK# for the unlock
case, since there are no ordering issues persay - the
"A" == Alexander Viro [EMAIL PROTECTED] writes:
A As for the "greater social good" (or world domination, for that
A matter) - excuse me, but quite a few of us couldn't care
A less.
Thanks for the comment, and please don't feel guilty about it, it is a
perfectly valid reason for
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
"Theodore Y. Ts'o" wrote:
If you come up with robust, easy to patch source-code-level debugger for
Linux, some people will use it, and some people won't. If it's better
than kdb, eventually it'll displace kdb as the external kernel
[EMAIL PROTECTED] wrote:
Now will you stop trying to incite pointless riots and allow those of us
who are trying to use linux-kernel as a useful means of communicating
development issues a chance for a decent signal to noise ratio?
-ben
Ben,
Read the thread before
One way of increasing signal to noise ratio (place in .procmailrc):
:0
* ^FROM.*jmerkey@timpanogas\.com
/dev/null
On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote:
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
snip
Now will you stop trying to incite pointless riots and allow
1 - 100 of 272 matches
Mail list logo
