Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: "Horst von Brand" <[EMAIL PROTECTED]>
> Problem is:
>
> - Debugging code has to be written, integrated and debugged. It has to be
> designed for collecting certain types of data. If you get the data to be
> collected wrong, it is useless (and as you don't know what bugs you are
> looking for, you _will_ get it wrong most of the time, unless you collect
> everything in sight)
> - Debugging code impacts readability, writeability, and performance of the
> instrumented code, specially if it is pervasive (and most functionality
> isn't localized)
> - Debugging harnesses have to evolve together with the instrumented
> code. If they don't, they are just a liability. If they do, they double
> (probably more) the development time, as they have to be kept in synch.
> - Broken debugging code impacts stability
>
> Do we want Linus & Co. writing cool kernel code or writing a whiz-bang
> kernel code debugger? Developer time _is_ finite, you know...
So you place your money into the bank until you have a "large enough sum
to be worth investing in a mutual fund or stock", I presume. If not then you
SHOULD understand the invest now for returns later ideas. If the time is
invested now the return on investment later will be far greater than if they
finally grudgingly try to do it later.
While I was at Magnavox I watched several software projects from
proposal through production code. The more time that was invested
up front in tools the more likely the project was to be on time and on
budget or even under budget. (And this was with that roundly dispised
thing called Ada. Go figure.)
I rather strongly think it is well past time to make the debugger
investment. But building a good one is hard to do. Where is someone
smart enough and capable enough to get the core built so that there
is a rational debugger project to parallel the kernel development?
It's not a glamorous job. But somebody ought to grit their teeth and
get their name on The Linux Kernel Debugger. I suspect the community
would remember THAT person a LONG time. I kinda wish I had the
time and that it better fit my skill sets. I know the people who fit the
project are out there earning REALLY big bucks from Raytheon
and Rockwell as well as some of the more often thought of companies.
> Witness the people who have argued _against_ integrating debugging code
> into the kernel, *even code they designed and wrote themselves*.
"If it was hard to design by God it should be hard to maintain, too."
> Check out stuff like the user-level kernel, AFAIU there it is possible to
> attach a run-of-the-mill debugger to a live kernel. Or look at the remote
> debugging stubs for gdb.
>
> It is not that they don't want better tools, the problem is that the tools
> available (or buildable at a reasonable cost) are woefully inadequate to
> the task at hand. Typical (low-level!) question when debugging is "Where
> the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and
> no current debugger is able to give you even that little. Sure, you can
> single-step to the point of failure, but it is often faster to just grep
> for the places where it can be changed. Don't even think about asking stuff
> like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario,
> the only useful tool is a good understanding of the kernel; instrumentation
> which gets more in the way than its usefulness warrants is just left out,
> or rots away.
Dr. Horst H. von Brand, I think you are pointing out one of the more
splendidly large worms in the Open Source apple. Better tools are
needed and if they exist they would be used. But nobody wants the
job. So it doesn't get done.
Alas, *I* do not have a solution other than maybe to embarrass someone
into doing what has to be done and geting intense satisfaction about that
when it is done.
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> > A good debugger is a very
> > good leveraging agent. I can cut a 2x4 with a largish pocket knife,
> > in theory. (I have never wasted the time.) In a pinch I have cut a
> > 2X4 with a hand saw. I can see that if I wanted to do this for any
> > serious work power tools are required. The same logic seems
> > to fall into the programming realm.
>
> I disagree. No one here is dumb enough to use a wholely inappropriate
> tool for a particular task. But using a debugger is often (but not
> always) like sawing bits off your 2x4 until it happens to fit the
> gap. What you need to do is to understand the problem parameters,
> measure them, mark your 2x4, then cut using whatever tool is best
> suited to the job. In woodwork the results tend to be superior :-)
>
> Mike
Sigh, one more try to get youse guys to understand.
I started out as an RF engineer. I note that I was considered damn good
at it. Part of the reason I worked the miracles I worked, designing radios
for the military with specifications straight out of science fiction, is tools.
The one indispensable tool was a deep understanding of which way the
electrons flow and how. Another was mathematics. A third is experience.
Without these basics no other tool would have led me to the solutions I
found.
But I also used other power tools. I built my own computer aided circuit
analysis program. With that program I found some problems early on
that would have kept me at the test bench for weeks tracking down. I
added one resistor to a variable tuned circuit and increased the circuit's
useable dynamic range 30dB. I confirmed it with another tool I consider
indispensable, the spectrum analyzer. A couple years later we got our
first network analyzer and I was in hog heaven. When we finally got a
computer controlled network analyzer I did even better. I wrote some
custom software for it that led to being able to calibrate the test set
for the GPS navigation data unit to 10 times the precision of the NDU
itself in 30 minutes from drag the equipment into the room to tear down.
When the poor sod from Bendix (the folks that made that iteration of the
NDU) who was visiting that day saw this he died. It took them a full day
to get to the same results AND they had not noticed some effects I
pointed out to him DURING that 30 minutes. *THIS* is what a debugger
is for. It is a window on the software you are attempting to debug that
allows even the best in the business to do better. I rather immodestly
lay claim to being one of the best RF engineers in the country in the
70s for high dynamic range antijam receivers and frequency synthesizers.
I might not have been so good except that I adopted tools and used them
WITH my knowledge gained from building ham radio equipment of my
own since the 9th grade. Experience, knowledge, AND TOOLS lead to
the best product. Cripple your tools and you cripple your product.
30 years of experience have proven this to me over and over again from
watching auto mechanics and ditch diggers through every engineering
discipline I have ever paused to observe. Only a damnfool eschews good
tools because of some sense of "pride" that doing it the caveman way
"forces me to think more." Son, if you need to be forced into thinking you
are in the wrong business. I got into SW because RF engineering was
getting boring and this was more challenging and fun. ('Sides, it gets VERY
tiring for a "guril" to fight most of the RF weenies her age who think that
since she is a "guril" she cannot POSSIBLY understand electrons. I had
to prove them wrong and fools too many times. I got bored. SW was more
"forgiving" in that regard. It allowed me more time to concentrate on
"doing it right and well." I figure I am "good" but not "great" with SW. Er,
the company I last worked for thought different. I got all the jobs nobody
else seemed able to do. Sadly I had to do most of them without adequate
tools. I really learned to like the leverage tools give. Tools do not SOLVE
the problems. But they leverage my knowledge so that *I* can solve the
problem. It is entirely up to me to have the self discipline to think through
what I can learn with the debugger until I have a solution that "makes
sense". "It works" does not always "make sense". So I usually do not
stop at "it works". That is being an adult and having some self discipline
as opposed to a being a child in a high tech playground. I get adult level
rewards and satisfaction that the children miss, too. The "hit" or the
"high" is greater the adult way.
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
-BEGIN PGP SIGNED MESSAGE- To do this, we need to be taught how. Where are the manuals for these potential power saws? What books do we read? What courses do we take? What websites do we visit? In short, wheres the beef? Where does one learn the theory and concepts that go into these "advanced" wonders of the information toolmaking economy? I recently got my copy of "Debugging with GDB" from the FSF. While it is a good start, far more is needed. "Deep C Secrets", while a valuable read, doesn't go much farther in the use of "power tools". Would any of you advocates of kernel debuggers and advanced debugging power tools show us their intended use? I do light construction around my house, but I'm not going to start using a jackhammer or chainsaw without getting at least a little instruction beforehand from someone who knows the business. I like to program in the same way. Jonathan Walther Developer, Lineo On Wed, 6 Sep 2000, Daniel Phillips wrote: > Mike Jagdis wrote: > > I disagree. No one here is dumb enough to use a wholely inappropriate > > tool for a particular task. But using a debugger is often (but not > > always) like sawing bits off your 2x4 until it happens to fit the > > gap. What you need to do is to understand the problem parameters, > > measure them, mark your 2x4, then cut using whatever tool is best > > suited to the job. In woodwork the results tend to be superior :-) > > Yes, you've put your finger on it. When you take a power saw and try > to use it like a chisel, it doesn't work very well. If you are > philosophically opposed to power saws, you may pick one up, try to use > it as a chisel, and then claim that it is a very poor tool. > > This is what is happening here. The proponents of the 'withhold the > power tools' camp have fixated on the idea of using a debugger to > chisel away at a problem. This is a poor way to use a debugger. > Instead, use the debugger to cut a large problem space into small > pieces - pieces that are too small for a bug to hide in. Use the > debugger as a power saw, not as a chisel, and you will have more > respect for its capabilities. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBObatR8K9HT/YfGeBAQEZkAP+J3zsBoNTt2+BeJkUaLmW+p7wgL0oy2PU PqnS5xU/QnmTmP+x5OSLtbXTQ55VqZBalY1gLK8DnjCyYy/JH8ckivWs84lIxRW7 60cDZWlx5bmg5OHx2dYRTibOvkFUmFQuDWjPhZebqeOX2M1g1UcSDrEQ8qReW8fg 9xQY4RkpSYE= =gs3d -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Mike Jagdis wrote: > I disagree. No one here is dumb enough to use a wholely inappropriate > tool for a particular task. But using a debugger is often (but not > always) like sawing bits off your 2x4 until it happens to fit the > gap. What you need to do is to understand the problem parameters, > measure them, mark your 2x4, then cut using whatever tool is best > suited to the job. In woodwork the results tend to be superior :-) Yes, you've put your finger on it. When you take a power saw and try to use it like a chisel, it doesn't work very well. If you are philosophically opposed to power saws, you may pick one up, try to use it as a chisel, and then claim that it is a very poor tool. This is what is happening here. The proponents of the 'withhold the power tools' camp have fixated on the idea of using a debugger to chisel away at a problem. This is a poor way to use a debugger. Instead, use the debugger to cut a large problem space into small pieces - pieces that are too small for a bug to hide in. Use the debugger as a power saw, not as a chisel, and you will have more respect for its capabilities. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"J. Dow" <[EMAIL PROTECTED]> said: [...] > I note again that the same arguement applies vis a vis printk > and desk checks with a paper and pencil. The printk leverages > the capable person's time. The kernel debugger leverages > the capable person's time. What IS this urge to be handicapped > when trying to debug the most important pieces of what gets > delivered on the distribution CDROMs. Problem is: - Debugging code has to be written, integrated and debugged. It has to be designed for collecting certain types of data. If you get the data to be collected wrong, it is useless (and as you don't know what bugs you are looking for, you _will_ get it wrong most of the time, unless you collect everything in sight) - Debugging code impacts readability, writeability, and performance of the instrumented code, specially if it is pervasive (and most functionality isn't localized) - Debugging harnesses have to evolve together with the instrumented code. If they don't, they are just a liability. If they do, they double (probably more) the development time, as they have to be kept in synch. - Broken debugging code impacts stability Do we want Linus & Co. writing cool kernel code or writing a whiz-bang kernel code debugger? Developer time _is_ finite, you know... Witness the people who have argued _against_ integrating debugging code into the kernel, *even code they designed and wrote themselves*. Check out stuff like the user-level kernel, AFAIU there it is possible to attach a run-of-the-mill debugger to a live kernel. Or look at the remote debugging stubs for gdb. It is not that they don't want better tools, the problem is that the tools available (or buildable at a reasonable cost) are woefully inadequate to the task at hand. Typical (low-level!) question when debugging is "Where the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and no current debugger is able to give you even that little. Sure, you can single-step to the point of failure, but it is often faster to just grep for the places where it can be changed. Don't even think about asking stuff like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario, the only useful tool is a good understanding of the kernel; instrumentation which gets more in the way than its usefulness warrants is just left out, or rots away. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> What IS this urge to be handicapped > when trying to debug the most important pieces of what gets > delivered on the distribution CDROMs. Is it, "I'm so hairy chested > that I can code with one metaphorical arm tied behind my > equally cliched back?" There are those that like to visualize things and there are those that like to experience them. Neither is _necessarily_ wrong but Linux tends to have more of the former, and the latter have yet to write what they consider to be a good kernel debugger. (Yes, a debugger is a tool for _experiencing_ not a tool for _visualizing_) > A good debugger is a very > good leveraging agent. I can cut a 2x4 with a largish pocket knife, > in theory. (I have never wasted the time.) In a pinch I have cut a > 2X4 with a hand saw. I can see that if I wanted to do this for any > serious work power tools are required. The same logic seems > to fall into the programming realm. I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: "Ingo Molnar" <[EMAIL PROTECTED]>
> > If the Kernel Debugger creates faulty solutions through lack of
> > thinking, and asking why, then surely printk is at least as bad
> > because it allows somebody to view the operation of the kernel through
> > a keyhole darkly. [...]
>
> i'd like to quote David here, because i cannot put it any simpler:
>
> " It is hoped that because it isn't the default, some new people
>will take the quantum leap to actually try debugging using the
>best debugger any of us have, our brains, instead of relying on
>automated tools. "
I note again that the same arguement applies vis a vis printk
and desk checks with a paper and pencil. The printk leverages
the capable person's time. The kernel debugger leverages
the capable person's time. What IS this urge to be handicapped
when trying to debug the most important pieces of what gets
delivered on the distribution CDROMs. Is it, "I'm so hairy chested
that I can code with one metaphorical arm tied behind my
equally cliched back?" Rather seriously this seems to be a
rather transparent attempt to keep the old boy's club closed
rather than an attempt to get the most bang for each old boy's
hour of debugging and coding time.
Good tools do not foster bad code. People foster bad code.
The converse is also true.
> my claim (which others share) is that we need more people who can debug
> the really tough problems (for which there are no tools in any OS) with
> their brains, and also we need people who will produce code with less bugs
> in the future.
And absense of tools fosters this? I would think it would drive many
serious people off figuring it is a fancy toy regardless of how effective
it may be serving up web pages for ever and ever amen.
In that regard I enjoy my "Yes!" (with a raised "I won" fist) reactions
when I finally knock down a problem. But I have gotten older now and
realize that 16 million seconds per year is about all I get on a practical
basis for generating these moments. I want to leverage my talents
for the best chances of creating these moments and knowing these
moments are valid and not spurious. A good debugger is a very
good leveraging agent. I can cut a 2x4 with a largish pocket knife,
in theory. (I have never wasted the time.) In a pinch I have cut a
2X4 with a hand saw. I can see that if I wanted to do this for any
serious work power tools are required. The same logic seems
to fall into the programming realm.
> There is also the important question of 'bug prevention'. The kernel isnt
> some magical soup which must be debugged only, code is *added* and
> debugged. If people who write code use more code reviews to fix bugs, then
> as a side-effect they'll sooner or later write code that is less prone to
> bugs. This is because they identify the bug-risks based on the code
> pattern - if you use a debugger mainly then you dont really see the code
> pattern but the current state of the system, which you validate. So the
> difference is this:
>
> - compare code, algorithm and concept with the original intention;
>analyze the symptoms and find the bug
>
> - compare the system state discovered through the debugger with the
>intended state of the system. Potentially step through the code before
>and after the faulty behavior, try to identify the 'point of bug' and
>constantly compare actual system state with intended system state.
>(it's certainly more complex than this, but you get the point.) This is
>why tools/features visualizing system state are so popular.
>
> i claim that the second behavior is 'passive', 'disconnected' and has no
> connection to the code itself, and thus tends to lead to inferior code. It
> leads to the frequent behavior of 'patching the state', not modifying the
> code itself. Eg. 'ok, we have a NULL here, lets return then so it wont
> crash later in the function.'
>
> The first behavior IMO produces a more 'integrated' coding style, where
> designing, writing and debugging code is closely interwoven, and naturally
> leads to higher quality code. Eg. 'we must never get a NULL here, who
> called this function and why??'.
This is all motherhood and has little or nothing to do with the presence or
absense of leveraging agents. Sure a dolt will produce more doltish code
per mega disk revolution with the leveraging agent than without. On the
other extremity a guru will produce more good code per mega disk
revolution, too.
Linux's Open Source nature leverages quantities of people fairly effectively.
Some attention appears to be needed to leverage the abilities of the few
GOOD people. (And I note that a good debugger is a good way to figure
out how the code works for some people who do not visualize from written
code all that well. Since Linux documentation is little or no better than NT
documentation these people are stranded unless they can see what is
happening "in vitro".)
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: "Ingo Molnar" <[EMAIL PROTECTED]>
>
> On Tue, 5 Sep 2000, Richard Gooch wrote:
>
> > Would you classify IKD as a pile of warts you wouldn't want to see in
> > the kernel?
>
> the quality of IKD is IMO excellent ( having written parts of it),
> yet i wouldnt want to see it in the kernel. That having said, i *did*
> author and integrate one of the IKD subsystems into the mainstream kernel
> - the NMI oopser on SMP systems. If a debugging aid is localized then
> there are no source-code health issues. In the case of the NMI-oopser the
> case was even clearer: nor a developer, nor a user can do anything useful
> with a hard lockup, apart from complaining that it 'locked up'. We clearly
> needed more information than that.
>
> KDB is not a code health issue either, it's quite localized. But KDB has
> the other bad social side-effect David was talking about, it promotes
> band-aids. So it's a tough call IMO.
I guess this has dragged on long enough I feel the urge to stick my
oversize sandles into the mess here.
For decades now I have observed that no tool ever makes a
"hack" into an "artist". All the tool does is allow both to make
their product, mess or art, quicker and with fewer basic errors.
A word processor does not turn the average Joe up the street
into an award winning novelist. But if it is reasonably well designed
there is a prayer that Joe will make fewer basic spelling or
textual errors.
A Kernel Debugger is just another such tool. It helps you find
"something interesting" quicker and with less pain. A great
debugger also offers you interesting views to help you
understand WHY what you are seeing is happening. If the
person using the debugger fails to ask that question he's
created his mess quicker. If the person using the debugger
asks the question and seriously ponders the answer the
kernel debugger is a handy tool for discovering why the
problem is happening. The kernel debugger, or any other
good debugging tool, gives the capable user a cleaner and
more efficient view of what is happening.
If the Kernel Debugger creates faulty solutions through lack
of thinking, and asking why, then surely printk is at least as
bad because it allows somebody to view the operation of
the kernel through a keyhole darkly. This view also fosters
"quick solutions" rather than careful analysis and desk
checking etc. Again, both are tools. They make things happen
quicker. In capable hands you get properly debugged code
quicker. In novice hands you get quicker bandaids placed on
the wrong sores. At least if the novice characterizes a problem
and points to a place where the problem is evident through
the patch presented the capable kernel author can start there
and use his or her thinking process more efficiently. It leverages
the capable person's abilities.
And in my limited experience with the NT kernel debugger you
sometimes can find problems that printk and looking at the same
code over and over again miss.
I guess the refrain is the same as the gun lovers refrain. Kernel
Debuggers do not create problems. People create problems.
{^_^}Joanne Dow, a "debugger" for most of my professional life,
both electronics hardware of many types and software.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"David S. Miller" wrote: > > From: Chris Wedgwood <[EMAIL PROTECTED]> > >Right now as I see it (pretending everything is black and white); >you, Dave, Linus and a few other people[1] are more than happy with >debugging aids as they exist right now in a stock kernel. > >However, there are many many other people far less talented than >yourselves and for use less capable people having a compile time >options of IKD or something might really be of use > > I think what it comes down to is that the folks who know the tree the > best and do the most work/fixing in it, think the debugging stuff > should remain a seperate patch. How do you fit Alan into that model? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
What IS this urge to be handicapped when trying to debug the most important pieces of what gets delivered on the distribution CDROMs. Is it, "I'm so hairy chested that I can code with one metaphorical arm tied behind my equally cliched back?" There are those that like to visualize things and there are those that like to experience them. Neither is _necessarily_ wrong but Linux tends to have more of the former, and the latter have yet to write what they consider to be a good kernel debugger. (Yes, a debugger is a tool for _experiencing_ not a tool for _visualizing_) A good debugger is a very good leveraging agent. I can cut a 2x4 with a largish pocket knife, in theory. (I have never wasted the time.) In a pinch I have cut a 2X4 with a hand saw. I can see that if I wanted to do this for any serious work power tools are required. The same logic seems to fall into the programming realm. I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"J. Dow" [EMAIL PROTECTED] said: [...] I note again that the same arguement applies vis a vis printk and desk checks with a paper and pencil. The printk leverages the capable person's time. The kernel debugger leverages the capable person's time. What IS this urge to be handicapped when trying to debug the most important pieces of what gets delivered on the distribution CDROMs. Problem is: - Debugging code has to be written, integrated and debugged. It has to be designed for collecting certain types of data. If you get the data to be collected wrong, it is useless (and as you don't know what bugs you are looking for, you _will_ get it wrong most of the time, unless you collect everything in sight) - Debugging code impacts readability, writeability, and performance of the instrumented code, specially if it is pervasive (and most functionality isn't localized) - Debugging harnesses have to evolve together with the instrumented code. If they don't, they are just a liability. If they do, they double (probably more) the development time, as they have to be kept in synch. - Broken debugging code impacts stability Do we want Linus Co. writing cool kernel code or writing a whiz-bang kernel code debugger? Developer time _is_ finite, you know... Witness the people who have argued _against_ integrating debugging code into the kernel, *even code they designed and wrote themselves*. Check out stuff like the user-level kernel, AFAIU there it is possible to attach a run-of-the-mill debugger to a live kernel. Or look at the remote debugging stubs for gdb. It is not that they don't want better tools, the problem is that the tools available (or buildable at a reasonable cost) are woefully inadequate to the task at hand. Typical (low-level!) question when debugging is "Where the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and no current debugger is able to give you even that little. Sure, you can single-step to the point of failure, but it is often faster to just grep for the places where it can be changed. Don't even think about asking stuff like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario, the only useful tool is a good understanding of the kernel; instrumentation which gets more in the way than its usefulness warrants is just left out, or rots away. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Mike Jagdis wrote: I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Yes, you've put your finger on it. When you take a power saw and try to use it like a chisel, it doesn't work very well. If you are philosophically opposed to power saws, you may pick one up, try to use it as a chisel, and then claim that it is a very poor tool. This is what is happening here. The proponents of the 'withhold the power tools' camp have fixated on the idea of using a debugger to chisel away at a problem. This is a poor way to use a debugger. Instead, use the debugger to cut a large problem space into small pieces - pieces that are too small for a bug to hide in. Use the debugger as a power saw, not as a chisel, and you will have more respect for its capabilities. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
-BEGIN PGP SIGNED MESSAGE- To do this, we need to be taught how. Where are the manuals for these potential power saws? What books do we read? What courses do we take? What websites do we visit? In short, wheres the beef? Where does one learn the theory and concepts that go into these "advanced" wonders of the information toolmaking economy? I recently got my copy of "Debugging with GDB" from the FSF. While it is a good start, far more is needed. "Deep C Secrets", while a valuable read, doesn't go much farther in the use of "power tools". Would any of you advocates of kernel debuggers and advanced debugging power tools show us their intended use? I do light construction around my house, but I'm not going to start using a jackhammer or chainsaw without getting at least a little instruction beforehand from someone who knows the business. I like to program in the same way. Jonathan Walther Developer, Lineo On Wed, 6 Sep 2000, Daniel Phillips wrote: Mike Jagdis wrote: I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Yes, you've put your finger on it. When you take a power saw and try to use it like a chisel, it doesn't work very well. If you are philosophically opposed to power saws, you may pick one up, try to use it as a chisel, and then claim that it is a very poor tool. This is what is happening here. The proponents of the 'withhold the power tools' camp have fixated on the idea of using a debugger to chisel away at a problem. This is a poor way to use a debugger. Instead, use the debugger to cut a large problem space into small pieces - pieces that are too small for a bug to hide in. Use the debugger as a power saw, not as a chisel, and you will have more respect for its capabilities. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBObatR8K9HT/YfGeBAQEZkAP+J3zsBoNTt2+BeJkUaLmW+p7wgL0oy2PU PqnS5xU/QnmTmP+x5OSLtbXTQ55VqZBalY1gLK8DnjCyYy/JH8ckivWs84lIxRW7 60cDZWlx5bmg5OHx2dYRTibOvkFUmFQuDWjPhZebqeOX2M1g1UcSDrEQ8qReW8fg 9xQY4RkpSYE= =gs3d -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
A good debugger is a very
good leveraging agent. I can cut a 2x4 with a largish pocket knife,
in theory. (I have never wasted the time.) In a pinch I have cut a
2X4 with a hand saw. I can see that if I wanted to do this for any
serious work power tools are required. The same logic seems
to fall into the programming realm.
I disagree. No one here is dumb enough to use a wholely inappropriate
tool for a particular task. But using a debugger is often (but not
always) like sawing bits off your 2x4 until it happens to fit the
gap. What you need to do is to understand the problem parameters,
measure them, mark your 2x4, then cut using whatever tool is best
suited to the job. In woodwork the results tend to be superior :-)
Mike
Sigh, one more try to get youse guys to understand.
I started out as an RF engineer. I note that I was considered damn good
at it. Part of the reason I worked the miracles I worked, designing radios
for the military with specifications straight out of science fiction, is tools.
The one indispensable tool was a deep understanding of which way the
electrons flow and how. Another was mathematics. A third is experience.
Without these basics no other tool would have led me to the solutions I
found.
But I also used other power tools. I built my own computer aided circuit
analysis program. With that program I found some problems early on
that would have kept me at the test bench for weeks tracking down. I
added one resistor to a variable tuned circuit and increased the circuit's
useable dynamic range 30dB. I confirmed it with another tool I consider
indispensable, the spectrum analyzer. A couple years later we got our
first network analyzer and I was in hog heaven. When we finally got a
computer controlled network analyzer I did even better. I wrote some
custom software for it that led to being able to calibrate the test set
for the GPS navigation data unit to 10 times the precision of the NDU
itself in 30 minutes from drag the equipment into the room to tear down.
When the poor sod from Bendix (the folks that made that iteration of the
NDU) who was visiting that day saw this he died. It took them a full day
to get to the same results AND they had not noticed some effects I
pointed out to him DURING that 30 minutes. *THIS* is what a debugger
is for. It is a window on the software you are attempting to debug that
allows even the best in the business to do better. I rather immodestly
lay claim to being one of the best RF engineers in the country in the
70s for high dynamic range antijam receivers and frequency synthesizers.
I might not have been so good except that I adopted tools and used them
WITH my knowledge gained from building ham radio equipment of my
own since the 9th grade. Experience, knowledge, AND TOOLS lead to
the best product. Cripple your tools and you cripple your product.
30 years of experience have proven this to me over and over again from
watching auto mechanics and ditch diggers through every engineering
discipline I have ever paused to observe. Only a damnfool eschews good
tools because of some sense of "pride" that doing it the caveman way
"forces me to think more." Son, if you need to be forced into thinking you
are in the wrong business. I got into SW because RF engineering was
getting boring and this was more challenging and fun. ('Sides, it gets VERY
tiring for a "guril" to fight most of the RF weenies her age who think that
since she is a "guril" she cannot POSSIBLY understand electrons. I had
to prove them wrong and fools too many times. I got bored. SW was more
"forgiving" in that regard. It allowed me more time to concentrate on
"doing it right and well." I figure I am "good" but not "great" with SW. Er,
the company I last worked for thought different. I got all the jobs nobody
else seemed able to do. Sadly I had to do most of them without adequate
tools. I really learned to like the leverage tools give. Tools do not SOLVE
the problems. But they leverage my knowledge so that *I* can solve the
problem. It is entirely up to me to have the self discipline to think through
what I can learn with the debugger until I have a solution that "makes
sense". "It works" does not always "make sense". So I usually do not
stop at "it works". That is being an adult and having some self discipline
as opposed to a being a child in a high tech playground. I get adult level
rewards and satisfaction that the children miss, too. The "hit" or the
"high" is greater the adult way.
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"David S. Miller" wrote: From: Chris Wedgwood [EMAIL PROTECTED] Right now as I see it (pretending everything is black and white); you, Dave, Linus and a few other people[1] are more than happy with debugging aids as they exist right now in a stock kernel. However, there are many many other people far less talented than yourselves and for use less capable people having a compile time options of IKD or something might really be of use I think what it comes down to is that the folks who know the tree the best and do the most work/fixing in it, think the debugging stuff should remain a seperate patch. How do you fit Alan into that model? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel debugging (was RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux)
I've debugged quiet a few operating systems on a very wide range of hardware over 25 years using a very wide range of tools and techniques, sometimes even having to use logic analysers. I've also watched this discussion for a while. IMHO, y'all have conflated two quiet different processes (possibly three,) and are trying to use your (lack of) tools as a form of social engineering. To the extent that computing is science, it is empirical science, and as such any effective tools that gives you visibility into the running computer belongs in your toolkit. A good (remote) source level debugger, *properly used*, is one of the most effective ways of obtaining visibility that I know. Tied in to a decent source code browser, it can also be a very effective way of coming up to speed on the ins and outs of someone else's code. There are, in essences, three parts to debugging a problem: figuring out what the system is really doing; figuring out why what it is doing is wrong; and figuring out the best way to make it behave less wrongly. Debuggers and source code browsers can figure prominently in the first (as should Meyer's programming contracts or a similar model backed up by real asserts in the code, but that's a different topic.) As I've posted earlier, our brains complement the computers, and we should use both most effectively. People are good at seeing patterns in the data, but not so good at extracting the data or remembering it. Good debuggers, effectively used, help with both the extraction and the remembering. Some people work best at identifying problems with abstraction and analysis. That's the way they should work. Others need hands on experience to identify problems. In the real world you need both kinds of people and you need to supply tools for each. Marty -Original Message- From: David S. Miller [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 05, 2000 5:03 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux Date: Wed, 6 Sep 2000 12:00:13 +1200 From: Chris Wedgwood <[EMAIL PROTECTED]> Right now as I see it (pretending everything is black and white); you, Dave, Linus and a few other people[1] are more than happy with debugging aids as they exist right now in a stock kernel. However, there are many many other people far less talented than yourselves and for use less capable people having a compile time options of IKD or something might really be of use I think what it comes down to is that the folks who know the tree the best and do the most work/fixing in it, think the debugging stuff should remain a seperate patch. We believe that it doesn't belong in the main source tree mainly for two reasons: 1) It is clutter. I don't want to see the debugging/debugger code when most of the time it serves no purpose. NOTE: This is different than "BUG()" and "ASSERT()" which serve a different purpose becuase they not only act as a consistency check, but they also _document_ how the author of the code believed the world around it must behave :-) 2) It is hoped that because it isn't the default, some new people will take the quantum leap to actually try debugging using the best debugger any of us have, our brains, instead of relying on automated tools. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Wed, Sep 06, 2000 at 12:31:55PM +1200, Chris Wedgwood wrote: > Perhaps you would like to describe how you do debug the kernel? I ask I find that rebooting the machine and cursing myself is one of the most effective kernel debugging methods. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Wed, 6 Sep 2000 12:31:55 +1200 From: Chris Wedgwood <[EMAIL PROTECTED]> Face it Dave -- you are just smarter than many of the rest of us. I would actually assert that I am not, and that I know the things I do for reasons other than "talent", and I think the best way to describe it is hard work. You might not need certain debugging aids, some people _right now_ do (at at the very least will benefit from them). True. Maybe debugging aids should be excluded from the kernel for various reasons, I'm not commenting on that, but expecting the rest of the world to get smarter all of a sudden isn't very realistic. I'm not expecting them to get smarter, I am expecting them to put in a little bit of hard work and become more familiar with how the kernel works. I want people to do a little bit of this, instead of stepping over a few instructions and examine a few variables from a debugger. That process does not increase familiarity, it is the study of behaviorology and _nothing_ more. You don't come from the debugger experience having learned how something works, however debugging using your brain does have this effect. Perhaps you would like to describe how you do debug the kernel? I ask this because I use printf more often than anything else when debugging userland code and I often use printk when debugging the kernel. Sure, no problem, I'll describe how it usually goes. %85 of cases requiring probing the kernel for info go something like: 1) Some evidence of kernel being in an incorrect state is made visible to me. Either this comes from an OOPS/etc. dump in an email, or someone prescribes a reproducable test case with which I can capture the dump on one of my systems. 2) Once dump is decoded, I determine what is most immediately wrong in the kernel at the moment the dump triggered. Ie. I decide that some part of some data structure is corrupt, or that some page cache page had ended up being used for an inode structure, etc. 3) Once I know the nature of the immedately incorrect state, I sit and think about how it would be possible arrive at that state. I try to walk backwards from the point of corruption back to where it may have originated. 4) Once I've got a decent idea of the ways such a corruption could possibly happen, I begin studying the kernel looking for places where the necessary set of conditions might be allowed. I verify these specific (and usually surrounding parts of) code for correctness. 5) If I am truly stumped I strategically place debugging checks from the point of corruption and gradually "upwards" in the event chains. Because I have taken the thinking time required in step #4 I will not spend much time rebooting over and over, 2 or 3 reboots and debugging check changes should be sufficient to capture the information I need to pinpoint the source of the problem. Actually, usually the phases are "run step 5, learn something from what is printed, iterate redoing step 4+5 until problem is spotted" And step 6 is reached when the true root cause of the bug is discovered :-) The other %15 entails situations where I code up specialized debugging code because capturing the specific set of conditions is nontrivial (for example, userspace seeing stale corrupt TLB translations, I have written code for sparc64 which validates the TLB to find such bugs). Only, with the former, I get to restart the application everytime it croaks, with the latter (modules excluded) I have to reboot. This is much more time consuming and means you really have to be much smarter about what checks and printk statements you put in where... the hope is with more intelligent debugging aids I can glean more information for each reboot. While you're rebooting you can come up with a game plan for steps 4 and 5 above, this is what I do. fsck time is "time to think". Ever have a situation where you were totally stumped on something, you go out and get a hamburger or something, and halfway through eating that juicy thing you're working out in your head the problem you're working on, and the solution just comes to you? This is the kind of process the above steps are meant to encourage. Discovery is IMHO one of the most fantastic parts of the human experiance. Now keep in mind, long ago I spent some inordinate amounts of time sprinkling printk's all over the place. And you can do this arbitrary poking to find bugs regardless of how much you know about the code, but it takes a long time. The goal is to learn how to sit, think, and study. Doing this instead of running immediately to the editor and trying to find an arbitrary new spot to stick a printk. Here's a suggestion, buy a pair of chinese balls, and upon reboot put some relevant source files into an editor on your screen and use your hands to play with the chinese balls. This is meant to fight the urge to just start typing,
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Wed, 6 Sep 2000 12:00:13 +1200 From: Chris Wedgwood <[EMAIL PROTECTED]> Right now as I see it (pretending everything is black and white); you, Dave, Linus and a few other people[1] are more than happy with debugging aids as they exist right now in a stock kernel. However, there are many many other people far less talented than yourselves and for use less capable people having a compile time options of IKD or something might really be of use I think what it comes down to is that the folks who know the tree the best and do the most work/fixing in it, think the debugging stuff should remain a seperate patch. We believe that it doesn't belong in the main source tree mainly for two reasons: 1) It is clutter. I don't want to see the debugging/debugger code when most of the time it serves no purpose. NOTE: This is different than "BUG()" and "ASSERT()" which serve a different purpose becuase they not only act as a consistency check, but they also _document_ how the author of the code believed the world around it must behave :-) 2) It is hoped that because it isn't the default, some new people will take the quantum leap to actually try debugging using the best debugger any of us have, our brains, instead of relying on automated tools. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
[EMAIL PROTECTED] (Jeff V. Merkey) writes: >> Yes, it seems so. So you're telling us that this entire thread is joke on >> your part? If not, then please show me the joke above or, for the future, >> mark your "jokes" somehow in the text so that dumbsticks like myself >can >> uderstand the jokes. Thank you. >> >Get off my ass. Why do you old people always have to get personal? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Alex Buell wrote: > > On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST, > you wrote: > > >Sorry, but I just don't take anything he says too seriously > >anymore... it's either trolling, or arguing mostly, or babbling > >about how much better other OS's are, but not actually using them > >for some reason... > > I just wish he'd get off the booze and skin up a nice spliff instead. I rolled spliffs in Germany. Was used to make them from turkish tobacco and red hash you could buy at Gruneberg Park in Frankfurt for 40 DM a stick when I was in my early 20's -- long time though. It's not a joke. It'w withdrawn until June 2001. And I have not drank since last year. I don't drink -- this is Utah. Where can you buy booze around here? Jeff > > Cheers, > Alex. > -- > This message has been ROT-13 encrypted twice for extra security. > > http://www.tahallah.clara.co.uk > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST, you wrote: >Sorry, but I just don't take anything he says too seriously >anymore... it's either trolling, or arguing mostly, or babbling >about how much better other OS's are, but not actually using them >for some reason... I just wish he'd get off the booze and skin up a nice spliff instead. Cheers, Alex. -- This message has been ROT-13 encrypted twice for extra security. http://www.tahallah.clara.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Marek Habersack wrote: > > ** On Sep 05, Jeff V. Merkey scribbled: > > > > Linux is more buggy than NT, but at least the source code comes with it > > > > so there's no excuse for not getting soeone to fix it > > > Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux > > > then?? Why don't you just stick with NT and improve NT? If you want NT > > > source - you can buy it from M$ and the only point that speaks against NT > > > (as it seems from reading your words) will vanish - you will have NT > > > sources, kernel debugger, nifty GUI for all the stuff, trained developers, > > > nice tech support. Let me ask you once again - why are you sticking with > > > Linux? > > > > I guess you don't know when people are joking. > Yes, it seems so. So you're telling us that this entire thread is joke on > your part? If not, then please show me the joke above or, for the future, > mark your "jokes" somehow in the text so that dumbsticks like myself can > uderstand the jokes. Thank you. > Get off my ass. Jeff > marek > > >Part 1.2Type: application/pgp-signature - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
** On Sep 05, Jeff V. Merkey scribbled: > > > Linux is more buggy than NT, but at least the source code comes with it > > > so there's no excuse for not getting soeone to fix it > > Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux > > then?? Why don't you just stick with NT and improve NT? If you want NT > > source - you can buy it from M$ and the only point that speaks against NT > > (as it seems from reading your words) will vanish - you will have NT > > sources, kernel debugger, nifty GUI for all the stuff, trained developers, > > nice tech support. Let me ask you once again - why are you sticking with > > Linux? > > I guess you don't know when people are joking. Yes, it seems so. So you're telling us that this entire thread is joke on your part? If not, then please show me the joke above or, for the future, mark your "jokes" somehow in the text so that dumbsticks like myself can uderstand the jokes. Thank you. marek PGP signature
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Marek Habersack wrote: > > ** On Sep 05, Jeff V. Merkey scribbled: > > > > Linux is more buggy than NT, but at least the source code comes with it > > so there's no excuse for not getting soeone to fix it > Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux > then?? Why don't you just stick with NT and improve NT? If you want NT > source - you can buy it from M$ and the only point that speaks against NT > (as it seems from reading your words) will vanish - you will have NT > sources, kernel debugger, nifty GUI for all the stuff, trained developers, > nice tech support. Let me ask you once again - why are you sticking with > Linux? I guess you don't know when people are joking. Jeff > > marek > > >Part 1.2Type: application/pgp-signature - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
** On Sep 05, Jeff V. Merkey scribbled: > > Linux is more buggy than NT, but at least the source code comes with it > so there's no excuse for not getting soeone to fix it Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux then?? Why don't you just stick with NT and improve NT? If you want NT source - you can buy it from M$ and the only point that speaks against NT (as it seems from reading your words) will vanish - you will have NT sources, kernel debugger, nifty GUI for all the stuff, trained developers, nice tech support. Let me ask you once again - why are you sticking with Linux? marek PGP signature
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Tue, Sep 05, 2000 at 01:03:49PM +0200, Ingo Molnar wrote: > one problem is developer laziness ;-) We could as well include debugging > code so that experienced people like you can fix easy / moderate bugs > quicker. But the problem is that in this case people are not forced to > understand the code as much as if the debugging tools were 'minimalistic' > like today. My point was basically that omitting useful debugging tools makes it not any less likely that people use the (A) strategy (easy fix instead of real understanding). For some people it is so painfull to work with raw dumps that they want to get out of that pain as quickly as possible, like with just adding an if (!ptr) return; and be done with it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Amen, The main issue for me is also for support. It's really nice to have an integrated kernel debugger so if a customer has a problem, you can send out trained folks to track stuff down more quickly since they can poke around the system. It's also great for diagnosing customer problems remotely. As for what Alan said, I say amen to every word and agree with everything he said. Jeff Alan Cox wrote: > > > This is why Linus does not allow a debugging facility like this into > > the kernel, so people spend time _thinking_ when they go hunting down > > bugs. > > I spend my time thinking. But I prefer to spend it thinking about the bug > not about finding it and how long fsck takes. There are only a few things I > think Linus is a complete loon about 8) but the debugging stuff is one. > > Things like GUI source level kernel debugging, nice graphs of things like > cache line reloads between two points and run time spinlock deadlock > validation and lock tracking (the last one is on my todo list only right now) > are rather useful > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"David S. Miller" wrote: > This is what a debugger does not do for you. The debugger allows you > to be lazy, step around, "oh yeah check for NULL" and never have to > _think_ about what you're doing or the changes you're making or even > if the same bug might be elsewhere. > > This is why Linus does not allow a debugging facility like this into > the kernel, so people spend time _thinking_ when they go hunting down > bugs. > > It takes longer to nail a bug, yes, but the resulting fix is always > far superior. And the person who discovers the bug leaves with a much > larger amount of knowledge about how that area of the kernel works. This is like working on an engine with the hood closed. Sure, you can feel around inside and you will *really* know a lot about your engine when you're finished but you are not necessarily using your time in the most efficient way. Personally, I will work with whatever tools are available, and if they're really seriously broken I'll stop working on the problem and go work on the tools instead. For the work I'm doing in Linux, the tools aren't quite so seriously broken, but that's just my specific work. I have worked extensively with source level debuggers on systems large and small - from IBM mainframes to embedded processors. I do not feel that my problem-solving abilities have suffered as a result. Normally, I spend a very long time in the design/analysis phase and a very short time in debugging. (The older I get, the more time I spend in analysis and the less in debugging.) In simple terms, working with a source level debugger frees up even more time to spend on analysis. More analysis is good. The best bug fix is the one you never have to make. Yes, I agree, some students will benefit from being forced to debug the good oldfashioned way, by pure intellect. But the Linux community as a whole benefits much more when we can make better use of the all-too-scarce programming hours of experienced developers. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> This is what a debugger does not do for you. The debugger allows you > to be lazy, step around, "oh yeah check for NULL" and never have to > _think_ about what you're doing or the changes you're making or even > if the same bug might be elsewhere. I don't really believe that. It is as easy to add a silly NULL pointer check based on a oops as it is after a debugging session (and it is even likely you chose the simple fix because it is harder and more work to proceed) Usually with the debugger it is at least easier to collect the data needed for a real fix. Usually when you fix something based on oops logs you have to often make a lot of assumptions because some knowledge is simply lost (like, what data did that structure contain exactly where I only see the pointer in the register?), and at least for me some of these "working theories" have turned out wrong sometimes. > This is why Linus does not allow a debugging facility like this into > the kernel, so people spend time _thinking_ when they go hunting down > bugs. What people do is that they start thinking where they can download i386 debugging stubs ;) > > It takes longer to nail a bug, yes, but the resulting fix is always > far superior. And the person who discovers the bug leaves with a much > larger amount of knowledge about how that area of the kernel works. That's for sure, although a single step can be sometimes very instructional too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Jeff Bob Taylor wrote: > > In message <[EMAIL PROTECTED]>, "Jeff V. Merkey" > writes: > cc: [EMAIL PROTECTED] > > > > > > Jes Sorensen wrote: > > > > > > > > Yeah I bet NT also has a wonderful graphical click click wush wush > > > environment for it that allows you to spend all your time `improving' > > > your rsi instead of getting real work done. Have you ever looked at NT > > > device driver code? I have, it's not pretty at all so I can understand > > > why you need all these tools. > > > > > > The kernel debugger in NT is text based and runs remotely only. It's > > very powerful and has facilties built in for debugging nested page > > faults and structured exceptions, SMP deadlocks, conditional > > breakpoints, and tons of other stuff not in Linux. Since Linux doesn't > > even support structured exception handling, it's not even a fair > > comparison between the two. > > If NTs debugger is so good then why is NT so buggy? Microsoft > doesn't know how to use it? > > Bob > > -- > +---+ > | Bob Taylor Email: [EMAIL PROTECTED]| > |---| > | Like the ad says, at 300 dpi you can tell she's wearing a | > | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | > | can tell it's painted on. I suppose at 2400 dpi you can tell | > | if the paint is giving her a rash. (So says Joshua R. Poulson)| > +---+ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Jeff Bob Taylor wrote: In message [EMAIL PROTECTED], "Jeff V. Merkey" writes: cc: [EMAIL PROTECTED] Jes Sorensen wrote: Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. The kernel debugger in NT is text based and runs remotely only. It's very powerful and has facilties built in for debugging nested page faults and structured exceptions, SMP deadlocks, conditional breakpoints, and tons of other stuff not in Linux. Since Linux doesn't even support structured exception handling, it's not even a fair comparison between the two. If NTs debugger is so good then why is NT so buggy? Microsoft doesn't know how to use it? Bob -- +---+ | Bob Taylor Email: [EMAIL PROTECTED]| |---| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
** On Sep 05, Jeff V. Merkey scribbled: Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux then?? Why don't you just stick with NT and improve NT? If you want NT source - you can buy it from M$ and the only point that speaks against NT (as it seems from reading your words) will vanish - you will have NT sources, kernel debugger, nifty GUI for all the stuff, trained developers, nice tech support. Let me ask you once again - why are you sticking with Linux? marek PGP signature
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Marek Habersack wrote: ** On Sep 05, Jeff V. Merkey scribbled: Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux then?? Why don't you just stick with NT and improve NT? If you want NT source - you can buy it from M$ and the only point that speaks against NT (as it seems from reading your words) will vanish - you will have NT sources, kernel debugger, nifty GUI for all the stuff, trained developers, nice tech support. Let me ask you once again - why are you sticking with Linux? I guess you don't know when people are joking. Jeff marek Part 1.2Type: application/pgp-signature - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
** On Sep 05, Jeff V. Merkey scribbled: Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux then?? Why don't you just stick with NT and improve NT? If you want NT source - you can buy it from M$ and the only point that speaks against NT (as it seems from reading your words) will vanish - you will have NT sources, kernel debugger, nifty GUI for all the stuff, trained developers, nice tech support. Let me ask you once again - why are you sticking with Linux? I guess you don't know when people are joking. Yes, it seems so. So you're telling us that this entire thread is joke on your part? If not, then please show me the joke above or, for the future, mark your "jokes" somehow in the text so that jokedumbsticks/joke like myself can uderstand the jokes. Thank you. marek PGP signature
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Marek Habersack wrote: ** On Sep 05, Jeff V. Merkey scribbled: Linux is more buggy than NT, but at least the source code comes with it so there's no excuse for not getting soeone to fix it Excuse me for adding my irrelevant 0.2$ - but what are you doing with Linux then?? Why don't you just stick with NT and improve NT? If you want NT source - you can buy it from M$ and the only point that speaks against NT (as it seems from reading your words) will vanish - you will have NT sources, kernel debugger, nifty GUI for all the stuff, trained developers, nice tech support. Let me ask you once again - why are you sticking with Linux? I guess you don't know when people are joking. Yes, it seems so. So you're telling us that this entire thread is joke on your part? If not, then please show me the joke above or, for the future, mark your "jokes" somehow in the text so that jokedumbsticks/joke like myself can uderstand the jokes. Thank you. Get off my ass. Jeff marek Part 1.2Type: application/pgp-signature - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST, you wrote: Sorry, but I just don't take anything he says too seriously anymore... it's either trolling, or arguing mostly, or babbling about how much better other OS's are, but not actually using them for some reason... I just wish he'd get off the booze and skin up a nice spliff instead. Cheers, Alex. -- This message has been ROT-13 encrypted twice for extra security. http://www.tahallah.clara.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Alex Buell wrote: On Tue, 5 Sep 2000 08:38:38 -0400 (EDT) Tue, 5 Sep 00 13:45:17 BST, you wrote: Sorry, but I just don't take anything he says too seriously anymore... it's either trolling, or arguing mostly, or babbling about how much better other OS's are, but not actually using them for some reason... I just wish he'd get off the booze and skin up a nice spliff instead. I rolled spliffs in Germany. Was used to make them from turkish tobacco and red hash you could buy at Gruneberg Park in Frankfurt for 40 DM a stick when I was in my early 20's -- long time though. It's not a joke. It'w withdrawn until June 2001. And I have not drank since last year. I don't drink -- this is Utah. Where can you buy booze around here? Yawn Jeff Cheers, Alex. -- This message has been ROT-13 encrypted twice for extra security. http://www.tahallah.clara.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Wed, 6 Sep 2000 12:31:55 +1200 From: Chris Wedgwood [EMAIL PROTECTED] Face it Dave -- you are just smarter than many of the rest of us. I would actually assert that I am not, and that I know the things I do for reasons other than "talent", and I think the best way to describe it is hard work. You might not need certain debugging aids, some people _right now_ do (at at the very least will benefit from them). True. Maybe debugging aids should be excluded from the kernel for various reasons, I'm not commenting on that, but expecting the rest of the world to get smarter all of a sudden isn't very realistic. I'm not expecting them to get smarter, I am expecting them to put in a little bit of hard work and become more familiar with how the kernel works. I want people to do a little bit of this, instead of stepping over a few instructions and examine a few variables from a debugger. That process does not increase familiarity, it is the study of behaviorology and _nothing_ more. You don't come from the debugger experience having learned how something works, however debugging using your brain does have this effect. Perhaps you would like to describe how you do debug the kernel? I ask this because I use printf more often than anything else when debugging userland code and I often use printk when debugging the kernel. Sure, no problem, I'll describe how it usually goes. %85 of cases requiring probing the kernel for info go something like: 1) Some evidence of kernel being in an incorrect state is made visible to me. Either this comes from an OOPS/etc. dump in an email, or someone prescribes a reproducable test case with which I can capture the dump on one of my systems. 2) Once dump is decoded, I determine what is most immediately wrong in the kernel at the moment the dump triggered. Ie. I decide that some part of some data structure is corrupt, or that some page cache page had ended up being used for an inode structure, etc. 3) Once I know the nature of the immedately incorrect state, I sit and think about how it would be possible arrive at that state. I try to walk backwards from the point of corruption back to where it may have originated. 4) Once I've got a decent idea of the ways such a corruption could possibly happen, I begin studying the kernel looking for places where the necessary set of conditions might be allowed. I verify these specific (and usually surrounding parts of) code for correctness. 5) If I am truly stumped I strategically place debugging checks from the point of corruption and gradually "upwards" in the event chains. Because I have taken the thinking time required in step #4 I will not spend much time rebooting over and over, 2 or 3 reboots and debugging check changes should be sufficient to capture the information I need to pinpoint the source of the problem. Actually, usually the phases are "run step 5, learn something from what is printed, iterate redoing step 4+5 until problem is spotted" And step 6 is reached when the true root cause of the bug is discovered :-) The other %15 entails situations where I code up specialized debugging code because capturing the specific set of conditions is nontrivial (for example, userspace seeing stale corrupt TLB translations, I have written code for sparc64 which validates the TLB to find such bugs). Only, with the former, I get to restart the application everytime it croaks, with the latter (modules excluded) I have to reboot. This is much more time consuming and means you really have to be much smarter about what checks and printk statements you put in where... the hope is with more intelligent debugging aids I can glean more information for each reboot. While you're rebooting you can come up with a game plan for steps 4 and 5 above, this is what I do. fsck time is "time to think". Ever have a situation where you were totally stumped on something, you go out and get a hamburger or something, and halfway through eating that juicy thing you're working out in your head the problem you're working on, and the solution just comes to you? This is the kind of process the above steps are meant to encourage. Discovery is IMHO one of the most fantastic parts of the human experiance. Now keep in mind, long ago I spent some inordinate amounts of time sprinkling printk's all over the place. And you can do this arbitrary poking to find bugs regardless of how much you know about the code, but it takes a long time. The goal is to learn how to sit, think, and study. Doing this instead of running immediately to the editor and trying to find an arbitrary new spot to stick a printk. Here's a suggestion, buy a pair of chinese balls, and upon reboot put some relevant source files into an editor on your screen and use your hands to play with the chinese balls. This is meant to fight the urge to just start typing, and
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Wed, Sep 06, 2000 at 12:31:55PM +1200, Chris Wedgwood wrote: Perhaps you would like to describe how you do debug the kernel? I ask I find that rebooting the machine and cursing myself is one of the most effective kernel debugging methods. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
This is what a debugger does not do for you. The debugger allows you to be lazy, step around, "oh yeah check for NULL" and never have to _think_ about what you're doing or the changes you're making or even if the same bug might be elsewhere. I don't really believe that. It is as easy to add a silly NULL pointer check based on a oops as it is after a debugging session (and it is even likely you chose the simple fix because it is harder and more work to proceed) Usually with the debugger it is at least easier to collect the data needed for a real fix. Usually when you fix something based on oops logs you have to often make a lot of assumptions because some knowledge is simply lost (like, what data did that structure contain exactly where I only see the pointer in the register?), and at least for me some of these "working theories" have turned out wrong sometimes. This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. What people do is that they start thinking where they can download i386 debugging stubs ;) It takes longer to nail a bug, yes, but the resulting fix is always far superior. And the person who discovers the bug leaves with a much larger amount of knowledge about how that area of the kernel works. That's for sure, although a single step can be sometimes very instructional too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"David S. Miller" wrote: This is what a debugger does not do for you. The debugger allows you to be lazy, step around, "oh yeah check for NULL" and never have to _think_ about what you're doing or the changes you're making or even if the same bug might be elsewhere. This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. It takes longer to nail a bug, yes, but the resulting fix is always far superior. And the person who discovers the bug leaves with a much larger amount of knowledge about how that area of the kernel works. This is like working on an engine with the hood closed. Sure, you can feel around inside and you will *really* know a lot about your engine when you're finished but you are not necessarily using your time in the most efficient way. Personally, I will work with whatever tools are available, and if they're really seriously broken I'll stop working on the problem and go work on the tools instead. For the work I'm doing in Linux, the tools aren't quite so seriously broken, but that's just my specific work. I have worked extensively with source level debuggers on systems large and small - from IBM mainframes to embedded processors. I do not feel that my problem-solving abilities have suffered as a result. Normally, I spend a very long time in the design/analysis phase and a very short time in debugging. (The older I get, the more time I spend in analysis and the less in debugging.) In simple terms, working with a source level debugger frees up even more time to spend on analysis. More analysis is good. The best bug fix is the one you never have to make. Yes, I agree, some students will benefit from being forced to debug the good oldfashioned way, by pure intellect. But the Linux community as a whole benefits much more when we can make better use of the all-too-scarce programming hours of experienced developers. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Amen, The main issue for me is also for support. It's really nice to have an integrated kernel debugger so if a customer has a problem, you can send out trained folks to track stuff down more quickly since they can poke around the system. It's also great for diagnosing customer problems remotely. As for what Alan said, I say amen to every word and agree with everything he said. Jeff Alan Cox wrote: This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one. Things like GUI source level kernel debugging, nice graphs of things like cache line reloads between two points and run time spinlock deadlock validation and lock tracking (the last one is on my todo list only right now) are rather useful - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Wed, 6 Sep 2000 12:00:13 +1200 From: Chris Wedgwood [EMAIL PROTECTED] Right now as I see it (pretending everything is black and white); you, Dave, Linus and a few other people[1] are more than happy with debugging aids as they exist right now in a stock kernel. However, there are many many other people far less talented than yourselves and for use less capable people having a compile time options of IKD or something might really be of use I think what it comes down to is that the folks who know the tree the best and do the most work/fixing in it, think the debugging stuff should remain a seperate patch. We believe that it doesn't belong in the main source tree mainly for two reasons: 1) It is clutter. I don't want to see the debugging/debugger code when most of the time it serves no purpose. NOTE: This is different than "BUG()" and "ASSERT()" which serve a different purpose becuase they not only act as a consistency check, but they also _document_ how the author of the code believed the world around it must behave :-) 2) It is hoped that because it isn't the default, some new people will take the quantum leap to actually try debugging using the best debugger any of us have, our brains, instead of relying on automated tools. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
FWIW, although this is an interesting theory, in my experience, having a good kernel debugger allows me *more* time to think clearly, rather than less. YMMV. IMHO, the division of labor between man and computer should be that each does what they are best at. In the case of debugging, this means letting the machine do the bookkeeping things that debuggers are good for. The best course is being able to solve the problem from first principles from a problem description and the source code. But there are plenty of time when the problem description is ambiguous, or the source code is someone else's but I need a fix anyway, or any of a thousand other reasons why I end up using a debugger. After all, if there is any science in "computer science", it is empirical science, and the debugger is a lab tool that allows me to quickly test hypothesis about the source of the problem. It has also never been my experience that taking longer to scope out the problem leads to a better fix. Quiet the contrary, especially when under time pressures. The sooner I can figure out what *is* broken, the more time I have to think about how best to fix it. While it may be true that (some) people spend more time thinking when they are debugging without a debugger, it is probably also true that most of that thought amounts to trying to figure out how to get the visibility the debugger would have given you. marty -Original Message- From: David S. Miller [mailto:[EMAIL PROTECTED]] Sent: Monday, September 04, 2000 5:04 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux Date:Sat, 02 Sep 2000 15:58:50 -0600 From: "Jeff V. Merkey" <[EMAIL PROTECTED]> I can only assume the reason for this is one of control, and that there are no valid technical reasons for it. I have spent more nights with printk() than I care to. And I bet the lessons learned and the issues involved in those nights with printk will never leave your brain, you will remember precisely in the future next time you see the same types of symptoms what kinds of things to look for and where. This is what a debugger does not do for you. The debugger allows you to be lazy, step around, "oh yeah check for NULL" and never have to _think_ about what you're doing or the changes you're making or even if the same bug might be elsewhere. This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. It takes longer to nail a bug, yes, but the resulting fix is always far superior. And the person who discovers the bug leaves with a much larger amount of knowledge about how that area of the kernel works. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Tue, 5 Sep 2000 01:13:51 +0100 (BST) From: Alan Cox <[EMAIL PROTECTED]> > This is why Linus does not allow a debugging facility like this into > the kernel, so people spend time _thinking_ when they go hunting down > bugs. I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one. I disagree, for the cases where I cannot for some reason reproduce the bug with / mounted read-only, the time it spends fsck'ing I spend _thinking_ about what possible causes are _instead_ of taping on the keyboard like a monkey. By the time the fsck completes, very often my brain has quiped "oh duh, yeah it's probably x and y doing z" and I'm in the home stretch of fully verifying the true cause of the bug. Seriously, this is one area where I am so happy we don't have fancy kernel debuggers in there by default. Fancy debuggers encourage the programmer to engage in behaviorology research, and _not_ in finding the true cause of a bug and fixing it properly. I take much comfort in the fact that 2 hackers who have been debugging programms probably longer that I have been alive (Kernighan and Pike) agree with me. See chapter 5 of their book "The Practice of Programming". Note in particular the second paragraph on page 119. Profiling and performance monitoring tools, they are useful too, but also as a seperate patch. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> This is why Linus does not allow a debugging facility like this into > the kernel, so people spend time _thinking_ when they go hunting down > bugs. I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one. Things like GUI source level kernel debugging, nice graphs of things like cache line reloads between two points and run time spinlock deadlock validation and lock tracking (the last one is on my todo list only right now) are rather useful - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date:Sat, 02 Sep 2000 15:58:50 -0600 From: "Jeff V. Merkey" <[EMAIL PROTECTED]> I can only assume the reason for this is one of control, and that there are no valid technical reasons for it. I have spent more nights with printk() than I care to. And I bet the lessons learned and the issues involved in those nights with printk will never leave your brain, you will remember precisely in the future next time you see the same types of symptoms what kinds of things to look for and where. This is what a debugger does not do for you. The debugger allows you to be lazy, step around, "oh yeah check for NULL" and never have to _think_ about what you're doing or the changes you're making or even if the same bug might be elsewhere. This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. It takes longer to nail a bug, yes, but the resulting fix is always far superior. And the person who discovers the bug leaves with a much larger amount of knowledge about how that area of the kernel works. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Tue, 5 Sep 2000 01:13:51 +0100 (BST) From: Alan Cox [EMAIL PROTECTED] This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one. I disagree, for the cases where I cannot for some reason reproduce the bug with / mounted read-only, the time it spends fsck'ing I spend _thinking_ about what possible causes are _instead_ of taping on the keyboard like a monkey. By the time the fsck completes, very often my brain has quiped "oh duh, yeah it's probably x and y doing z" and I'm in the home stretch of fully verifying the true cause of the bug. Seriously, this is one area where I am so happy we don't have fancy kernel debuggers in there by default. Fancy debuggers encourage the programmer to engage in behaviorology research, and _not_ in finding the true cause of a bug and fixing it properly. I take much comfort in the fact that 2 hackers who have been debugging programms probably longer that I have been alive (Kernighan and Pike) agree with me. See chapter 5 of their book "The Practice of Programming". Note in particular the second paragraph on page 119. Profiling and performance monitoring tools, they are useful too, but also as a seperate patch. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date:Sat, 02 Sep 2000 15:58:50 -0600 From: "Jeff V. Merkey" [EMAIL PROTECTED] I can only assume the reason for this is one of control, and that there are no valid technical reasons for it. I have spent more nights with printk() than I care to. And I bet the lessons learned and the issues involved in those nights with printk will never leave your brain, you will remember precisely in the future next time you see the same types of symptoms what kinds of things to look for and where. This is what a debugger does not do for you. The debugger allows you to be lazy, step around, "oh yeah check for NULL" and never have to _think_ about what you're doing or the changes you're making or even if the same bug might be elsewhere. This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. It takes longer to nail a bug, yes, but the resulting fix is always far superior. And the person who discovers the bug leaves with a much larger amount of knowledge about how that area of the kernel works. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
This is why Linus does not allow a debugging facility like this into the kernel, so people spend time _thinking_ when they go hunting down bugs. I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one. Things like GUI source level kernel debugging, nice graphs of things like cache line reloads between two points and run time spinlock deadlock validation and lock tracking (the last one is on my todo list only right now) are rather useful - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> contributing member of Linux for quite some time, however, the > architecture of Linux is unnatural to Novell's and Microsoft's > technologies and Linux is at present incapable of providing the same > level of Networking capability available with Windows 2000 or NetWare to > enterprise customers. NetWare routinely supports upwards of 2000 users This again confirms that any mention of the word "enterprise" in press releases and the like really means just "we're only accustomed to the Windows programming model, so from _our_ perspective everything else looks inferior". > per server for file and print. Linux with it's current level of > development has trouble with configurations of more than 100 users via > MARS-NWE or SAMBA in our tests. TRG's MANOS source code and components In part because a sizable portion of development resources in those projects was spent deciphering the undocumented protocols rather than implementing/optimizing them? Try any NT-based SMTP/IMAP mail server, for a large enterprise, in contrast. Compare it with any Un*x solution. The specs have been public down to the last bit for 20 years (and we should assume that M$ engineers are at least capable of reading). Olaf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
In message <[EMAIL PROTECTED]>, "Jeff V. Merkey" writes: cc: [EMAIL PROTECTED] > > > Jes Sorensen wrote: > > > > > Yeah I bet NT also has a wonderful graphical click click wush wush > > environment for it that allows you to spend all your time `improving' > > your rsi instead of getting real work done. Have you ever looked at NT > > device driver code? I have, it's not pretty at all so I can understand > > why you need all these tools. > > > The kernel debugger in NT is text based and runs remotely only. It's > very powerful and has facilties built in for debugging nested page > faults and structured exceptions, SMP deadlocks, conditional > breakpoints, and tons of other stuff not in Linux. Since Linux doesn't > even support structured exception handling, it's not even a fair > comparison between the two. If NTs debugger is so good then why is NT so buggy? Microsoft doesn't know how to use it? Bob -- +---+ | Bob Taylor Email: [EMAIL PROTECTED]| |---| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
In message [EMAIL PROTECTED], "Jeff V. Merkey" writes: cc: [EMAIL PROTECTED] Jes Sorensen wrote: Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. The kernel debugger in NT is text based and runs remotely only. It's very powerful and has facilties built in for debugging nested page faults and structured exceptions, SMP deadlocks, conditional breakpoints, and tons of other stuff not in Linux. Since Linux doesn't even support structured exception handling, it's not even a fair comparison between the two. If NTs debugger is so good then why is NT so buggy? Microsoft doesn't know how to use it? Bob -- +---+ | Bob Taylor Email: [EMAIL PROTECTED]| |---| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff V. Merkey" wrote: I've got a lot of responses to this. Any companies out there who have job postings and the need for some talented networking engineers in Utah, please send us the info so we can post it on our website. If there's Linux work, these guys can do what we did, and learn Linux and work on that. Send the info to [EMAIL PROTECTED] and I'll post the job listings on our website. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Andi Kleen wrote: > > It works today, but won't in the future. At some point, real sleep > > locks will be needed for SMP tuning since you can give them prioities > > and put deadlock detection into the sleep locks for apps. Priority > > inheritance allows you to bump the priority of folks holding a bunch of > > sleep locks so they release them more quickly. SCO Unix uses them and > > that's why it's TCP-C numbers are almost 5 times what Linux's are with a > > database. You'll need them to keep Linux competitive when Caldera ships > > their SCO Unix version. > > That remains to be seen. Complex locking does not necessarily look like > the true path to performance. I watched the USL guys numbers get higher and higher when they put this stuff in their kernel and tuned it. I admit, I wasn't a believer either until I saw their numbers in 1995, but I became one -- numbers don't lie. Jeff > > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> > line and executes very simple commands like read memory etc.). I don't > > see much point in debugging that. > > Uless of course you need to debug the serial driver -- then you're > fucked. Wrong. Please RTFM on the gdb stubs. If you are going to get into an argument doing your research first is considered polite. gdb stubs can debug pretty much anything except the boot up 16->32bit transition. You can debug an NMI with it for that matter. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Andi Kleen wrote: > > On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote: > > > > > Of course not. Linux does not have a kernel debugger, or it would use > > them. That's what they are used for -- debugging running tasks from a > > kernel debugger that has it's own task gates. If you have nested task > > gates, then you can debug the kernel debugger with them. > > It just does not seem to be needed. The remote gdb stub is so simple > that it is probably not worth it (it just reads packets from the serial > line and executes very simple commands like read memory etc.). I don't > see much point in debugging that. Uless of course you need to debug the serial driver -- then you're fucked. > > > > priority being interrupts/bhs). Also the sleep locking seems to be generally > > > simple enough that it is not a problem for user processes. > > > > It will be when Linux finally implements real sleep locks in the kernel > > instead of aliased semaphores. > > No doubt. I admit even gdb support for that is very poor (=non existent), > but the Linux strategy of avoiding problems with that by using very > simple locking seems to have worked reasonably so far. It works today, but won't in the future. At some point, real sleep locks will be needed for SMP tuning since you can give them prioities and put deadlock detection into the sleep locks for apps. Priority inheritance allows you to bump the priority of folks holding a bunch of sleep locks so they release them more quickly. SCO Unix uses them and that's why it's TCP-C numbers are almost 5 times what Linux's are with a database. You'll need them to keep Linux competitive when Caldera ships their SCO Unix version. Jeff > > [but it didn't work for you, sorry] > > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote: > > > Andi Kleen wrote: > > > > On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote: > > > > > > KDB is putrid. Can it debug double faults? NO. Can it debug complex > > > register and numeric evaluation statements like IF ((EAX == 1) && > > > [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? > > > > remote gdb does that fine. > > > > I've never seen a nested task gate on Linux... > > Of course not. Linux does not have a kernel debugger, or it would use > them. That's what they are used for -- debugging running tasks from a > kernel debugger that has it's own task gates. If you have nested task > gates, then you can debug the kernel debugger with them. It just does not seem to be needed. The remote gdb stub is so simple that it is probably not worth it (it just reads packets from the serial line and executes very simple commands like read memory etc.). I don't see much point in debugging that. > > priority being interrupts/bhs). Also the sleep locking seems to be generally > > simple enough that it is not a problem for user processes. > > It will be when Linux finally implements real sleep locks in the kernel > instead of aliased semaphores. No doubt. I admit even gdb support for that is very poor (=non existent), but the Linux strategy of avoiding problems with that by using very simple locking seems to have worked reasonably so far. [but it didn't work for you, sorry] -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Andi Kleen wrote: > > On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote: > > > > KDB is putrid. Can it debug double faults? NO. Can it debug complex > > register and numeric evaluation statements like IF ((EAX == 1) && > > [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? > > remote gdb does that fine. > > I've never seen a nested task gate on Linux... Of course not. Linux does not have a kernel debugger, or it would use them. That's what they are used for -- debugging running tasks from a kernel debugger that has it's own task gates. If you have nested task gates, then you can debug the kernel debugger with them. > > > NO. Can it debug SMP locks races? NO. Can it debug priority inversion > > problems in sleep locks? NO. > > Given. Priority inversion does not seem to be a big problem in Linux though > (kernel threads usually run at the same priority, with the only higher > priority being interrupts/bhs). Also the sleep locking seems to be generally > simple enough that it is not a problem for user processes. It will be when Linux finally implements real sleep locks in the kernel instead of aliased semaphores. > > > Can the Kernel debugger in NetWare? YES. Can the Kernel Debugger in > > NT? YES. > > I guess they need it ;) I need it. Jeff > > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Alan Cox wrote: > > Remote gdb on Linux - yes and I can do my debugging source level. Unfortunately > Linus seems to have a one man campaign against putting sensible debugging into > his kernel. > > The tools exist and they should be in the x86 tree as well as sparc etc where > with other maintainers it is present > > gdb>b netif_rx > .. > gdb>where > > Alan I can only assume the reason for this is one of control, and that there are no valid technical reasons for it. I have spent more nights with printk() than I care to. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Jes Sorensen wrote: > > Yeah I bet NT also has a wonderful graphical click click wush wush > environment for it that allows you to spend all your time `improving' > your rsi instead of getting real work done. Have you ever looked at NT > device driver code? I have, it's not pretty at all so I can understand > why you need all these tools. The kernel debugger in NT is text based and runs remotely only. It's very powerful and has facilties built in for debugging nested page faults and structured exceptions, SMP deadlocks, conditional breakpoints, and tons of other stuff not in Linux. Since Linux doesn't even support structured exception handling, it's not even a fair comparison between the two. Jeff > > Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote: > > KDB is putrid. Can it debug double faults? NO. Can it debug complex > register and numeric evaluation statements like IF ((EAX == 1) && > [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? remote gdb does that fine. I've never seen a nested task gate on Linux... > NO. Can it debug SMP locks races? NO. Can it debug priority inversion > problems in sleep locks? NO. Given. Priority inversion does not seem to be a big problem in Linux though (kernel threads usually run at the same priority, with the only higher priority being interrupts/bhs). Also the sleep locking seems to be generally simple enough that it is not a problem for user processes. > Can the Kernel debugger in NetWare? YES. Can the Kernel Debugger in > NT? YES. I guess they need it ;) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> KDB is putrid. Can it debug double faults? NO. Can it debug Jeff> complex register and numeric evaluation statements like IF ((EAX Jeff> == 1) && [ESP-4] == 0x3000)? NO. Can it debug nested task gate Jeff> exceptions? NO. Can it debug SMP locks races? NO. Can it Jeff> debug priority inversion problems in sleep locks? NO. Oh you're telling us that you are not able to figure out what those lines of C turn into in assembly so you can set a break point yourself? Jeff> Can the Kernel debugger in NetWare? YES. Can the Kernel Jeff> Debugger in NT? YES. Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> KDB is putrid. Can it debug double faults? NO. Can it debug complex > register and numeric evaluation statements like IF ((EAX == 1) && > [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? > NO. Can it debug SMP locks races? NO. Can it debug priority inversion > problems in sleep locks? NO. > > Can the Kernel debugger in NetWare? YES. Can the Kernel Debugger in > NT? YES. Remote gdb on Linux - yes and I can do my debugging source level. Unfortunately Linus seems to have a one man campaign against putting sensible debugging into his kernel. The tools exist and they should be in the x86 tree as well as sparc etc where with other maintainers it is present gdb>b netif_rx .. gdb>where Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
KDB is putrid. Can it debug double faults? NO. Can it debug complex register and numeric evaluation statements like IF ((EAX == 1) && [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? NO. Can it debug SMP locks races? NO. Can it debug priority inversion problems in sleep locks? NO. Can the Kernel debugger in NetWare? YES. Can the Kernel Debugger in NT? YES. Jeff Jes Sorensen wrote: > > > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: > > Jeff> TRG has reprioritized it's long term objectives, and due to > Jeff> resource constraints and short term schedules, the Open Source > Jeff> NDS and Open Source NTFS File System projects are being > Jeff> withdrawn from the Linux Initiative. These projects will be > Jeff> MANOS only, and any interested party is free to acquire the code > Jeff> and back port them into Linux, though the networking > Jeff> architectures are profoundly different between the two. The > Jeff> lack of a Kernel Debugger and other basic kernel level > Jeff> facilities on Linux make TRG's job about 20 times harder on > Jeff> Linux and take almost 10 times as long as is possible on NT, > Jeff> NetWare, or MANOS to develop software asa result ofthis. > > If you want to pull out just do so. However, if you need an excuse > please try to use facts and not vapour: we do have a kernel debugger > for instance. It's called KDB and has been around for quite a while, > you just have to download it and patch your kernel for it (which is > not an unreasonable request if you are working on the kernel in the > first place). > > Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> TRG has reprioritized it's long term objectives, and due to Jeff> resource constraints and short term schedules, the Open Source Jeff> NDS and Open Source NTFS File System projects are being Jeff> withdrawn from the Linux Initiative. These projects will be Jeff> MANOS only, and any interested party is free to acquire the code Jeff> and back port them into Linux, though the networking Jeff> architectures are profoundly different between the two. The Jeff> lack of a Kernel Debugger and other basic kernel level Jeff> facilities on Linux make TRG's job about 20 times harder on Jeff> Linux and take almost 10 times as long as is possible on NT, Jeff> NetWare, or MANOS to develop software asa result ofthis. If you want to pull out just do so. However, if you need an excuse please try to use facts and not vapour: we do have a kernel debugger for instance. It's called KDB and has been around for quite a while, you just have to download it and patch your kernel for it (which is not an unreasonable request if you are working on the kernel in the first place). Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
TRG has reprioritized it's long term objectives, and due to resource constraints and short term schedules, the Open Source NDS and Open Source NTFS File System projects are being withdrawn from the Linux Initiative. These projects will be MANOS only, and any interested party is free to acquire the code and back port them into Linux, though the networking architectures are profoundly different between the two. The lack of a Kernel Debugger and other basic kernel level facilities on Linux make TRG's job about 20 times harder on Linux and take almost 10 times as long as is possible on NT, NetWare, or MANOS to develop software asa result ofthis. To date, TRG has invested over $1,500,000.00 on Linux development projects enabling NetWare-to-Linux interoperability so we feel like we have contributed erstwhile resources to date. Downloads of NWFS has exceeded 900,000 copies to date from TRG's website. TRG will continue to support NWFS on Linux as a migration file system for NetWare-to-Linux Migration, however, all new development will be on the MANOS platform only. M2FS for Linux will be available in binary form only for those interested parties. A press release will be sent on Monday informing the industry that TRG has withdrawn these projects in Open Source form on Linux and citing the reasons for this decision. As for the reasons behind this decision, TRG has attempted to be an contributing member of Linux for quite some time, however, the architecture of Linux is unnatural to Novell's and Microsoft's technologies and Linux is at present incapable of providing the same level of Networking capability available with Windows 2000 or NetWare to enterprise customers. NetWare routinely supports upwards of 2000 users per server for file and print. Linux with it's current level of development has trouble with configurations of more than 100 users via MARS-NWE or SAMBA in our tests. TRG's MANOS source code and components are freely available to the Linux community, and TRG has no objection to continued participation with the Linux Community and use of any of it's source code in Linux projects. Very Truly Yours, Jeff Merkey CEO, TRG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
TRG has reprioritized it's long term objectives, and due to resource constraints and short term schedules, the Open Source NDS and Open Source NTFS File System projects are being withdrawn from the Linux Initiative. These projects will be MANOS only, and any interested party is free to acquire the code and back port them into Linux, though the networking architectures are profoundly different between the two. The lack of a Kernel Debugger and other basic kernel level facilities on Linux make TRG's job about 20 times harder on Linux and take almost 10 times as long as is possible on NT, NetWare, or MANOS to develop software asa result ofthis. To date, TRG has invested over $1,500,000.00 on Linux development projects enabling NetWare-to-Linux interoperability so we feel like we have contributed erstwhile resources to date. Downloads of NWFS has exceeded 900,000 copies to date from TRG's website. TRG will continue to support NWFS on Linux as a migration file system for NetWare-to-Linux Migration, however, all new development will be on the MANOS platform only. M2FS for Linux will be available in binary form only for those interested parties. A press release will be sent on Monday informing the industry that TRG has withdrawn these projects in Open Source form on Linux and citing the reasons for this decision. As for the reasons behind this decision, TRG has attempted to be an contributing member of Linux for quite some time, however, the architecture of Linux is unnatural to Novell's and Microsoft's technologies and Linux is at present incapable of providing the same level of Networking capability available with Windows 2000 or NetWare to enterprise customers. NetWare routinely supports upwards of 2000 users per server for file and print. Linux with it's current level of development has trouble with configurations of more than 100 users via MARS-NWE or SAMBA in our tests. TRG's MANOS source code and components are freely available to the Linux community, and TRG has no objection to continued participation with the Linux Community and use of any of it's source code in Linux projects. Very Truly Yours, Jeff Merkey CEO, TRG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff TRG has reprioritized it's long term objectives, and due to Jeff resource constraints and short term schedules, the Open Source Jeff NDS and Open Source NTFS File System projects are being Jeff withdrawn from the Linux Initiative. These projects will be Jeff MANOS only, and any interested party is free to acquire the code Jeff and back port them into Linux, though the networking Jeff architectures are profoundly different between the two. The Jeff lack of a Kernel Debugger and other basic kernel level Jeff facilities on Linux make TRG's job about 20 times harder on Jeff Linux and take almost 10 times as long as is possible on NT, Jeff NetWare, or MANOS to develop software asa result ofthis. If you want to pull out just do so. However, if you need an excuse please try to use facts and not vapour: we do have a kernel debugger for instance. It's called KDB and has been around for quite a while, you just have to download it and patch your kernel for it (which is not an unreasonable request if you are working on the kernel in the first place). Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
KDB is putrid. Can it debug double faults? NO. Can it debug complex register and numeric evaluation statements like IF ((EAX == 1) [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? NO. Can it debug SMP locks races? NO. Can it debug priority inversion problems in sleep locks? NO. Can the Kernel debugger in NetWare? YES. Can the Kernel Debugger in NT? YES. Remote gdb on Linux - yes and I can do my debugging source level. Unfortunately Linus seems to have a one man campaign against putting sensible debugging into his kernel. The tools exist and they should be in the x86 tree as well as sparc etc where with other maintainers it is present gdbb netif_rx .. gdbwhere Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff KDB is putrid. Can it debug double faults? NO. Can it debug Jeff complex register and numeric evaluation statements like IF ((EAX Jeff == 1) [ESP-4] == 0x3000)? NO. Can it debug nested task gate Jeff exceptions? NO. Can it debug SMP locks races? NO. Can it Jeff debug priority inversion problems in sleep locks? NO. Oh you're telling us that you are not able to figure out what those lines of C turn into in assembly so you can set a break point yourself? Jeff Can the Kernel debugger in NetWare? YES. Can the Kernel Jeff Debugger in NT? YES. Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Jes Sorensen wrote: Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. The kernel debugger in NT is text based and runs remotely only. It's very powerful and has facilties built in for debugging nested page faults and structured exceptions, SMP deadlocks, conditional breakpoints, and tons of other stuff not in Linux. Since Linux doesn't even support structured exception handling, it's not even a fair comparison between the two. Jeff Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote: Andi Kleen wrote: On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote: KDB is putrid. Can it debug double faults? NO. Can it debug complex register and numeric evaluation statements like IF ((EAX == 1) [ESP-4] == 0x3000)? NO. Can it debug nested task gate exceptions? remote gdb does that fine. I've never seen a nested task gate on Linux... Of course not. Linux does not have a kernel debugger, or it would use them. That's what they are used for -- debugging running tasks from a kernel debugger that has it's own task gates. If you have nested task gates, then you can debug the kernel debugger with them. It just does not seem to be needed. The remote gdb stub is so simple that it is probably not worth it (it just reads packets from the serial line and executes very simple commands like read memory etc.). I don't see much point in debugging that. priority being interrupts/bhs). Also the sleep locking seems to be generally simple enough that it is not a problem for user processes. It will be when Linux finally implements real sleep locks in the kernel instead of aliased semaphores. No doubt. I admit even gdb support for that is very poor (=non existent), but the Linux strategy of avoiding problems with that by using very simple locking seems to have worked reasonably so far. [but it didn't work for you, sorry] -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Andi Kleen wrote: On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote: Of course not. Linux does not have a kernel debugger, or it would use them. That's what they are used for -- debugging running tasks from a kernel debugger that has it's own task gates. If you have nested task gates, then you can debug the kernel debugger with them. It just does not seem to be needed. The remote gdb stub is so simple that it is probably not worth it (it just reads packets from the serial line and executes very simple commands like read memory etc.). I don't see much point in debugging that. Uless of course you need to debug the serial driver -- then you're fucked. priority being interrupts/bhs). Also the sleep locking seems to be generally simple enough that it is not a problem for user processes. It will be when Linux finally implements real sleep locks in the kernel instead of aliased semaphores. No doubt. I admit even gdb support for that is very poor (=non existent), but the Linux strategy of avoiding problems with that by using very simple locking seems to have worked reasonably so far. It works today, but won't in the future. At some point, real sleep locks will be needed for SMP tuning since you can give them prioities and put deadlock detection into the sleep locks for apps. Priority inheritance allows you to bump the priority of folks holding a bunch of sleep locks so they release them more quickly. SCO Unix uses them and that's why it's TCP-C numbers are almost 5 times what Linux's are with a database. You'll need them to keep Linux competitive when Caldera ships their SCO Unix version. Jeff [but it didn't work for you, sorry] -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff V. Merkey" wrote: I've got a lot of responses to this. Any companies out there who have job postings and the need for some talented networking engineers in Utah, please send us the info so we can post it on our website. If there's Linux work, these guys can do what we did, and learn Linux and work on that. Send the info to [EMAIL PROTECTED] and I'll post the job listings on our website. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
