[ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Sat Sep 02 2000 - 16:00:20 EST 



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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Jes Sorensen (jes@linuxcare.com)
Date: Sat Sep 02 2000 - 16:31:15 EST 


>>>>> "Jeff" == Jeff V Merkey <jmerkey@timpanogas.com> 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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Sat Sep 02 2000 - 16:34:47 EST 


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 <jmerkey@timpanogas.com> 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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Sat Sep 02 2000 - 16:36:42 EST 


> 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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Sat Sep 02 2000 - 16:58:50 EST 


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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Andre Hedrick (andre@linux-ide.org)
Date: Sat Sep 02 2000 - 22:27:39 EST 


Jeff, 


Have you been in the bottle again? 
If this is not a joke, it is not funny. 


On Sat, 2 Sep 2000, Jeff V. Merkey wrote: 


> 
> 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 majordomo@vger.kernel.org 
> Please read the FAQ at http://www.tux.org/lkml/ 
> 


Andre Hedrick 
The Linux ATA/IDE guy 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Sat Sep 02 2000 - 22:42:35 EST 


Andre, 


One of our best friends we've known for years tried to kill himself when 
Novell layed him off. I will reconsider later, but not now. Not with 
what's going on at Novell. If we post it, Microsoft will grab it and it 
will be in NT within 48 hours of them downloading it from our site. 
Linux, NT, NetWare, NWFS, NDS, cars, houses, money -- these are all 
things, and things can be replaced. Lives cannot. Linux can wait a few 
months until the dust settles at Novell. 


We also spend too much debugging other peoples buggy code in Linux and 
our own buggy code with printk() and kdb. A lot of the types of 
problems we see, like SMP memory corruption are impossible to debug with 
KDB. I've given Linus the code for a killer kernel debugger, but he has 
not shown any proactive interest in wanting to leverage it. I am 
spending 4X the $$$ paying engineers than I should. Example: NWFS on 
NT took four months to develop and productize. I have been working on 
NWFS on Linux for 18 months, and still not all the issues are resolved. 
A kernel debugger would make all our lives easier and cost me less money 
in salaries to engineers for particular projects. 


Jeff 


Andre Hedrick wrote: 
> 
> Jeff, 
> 
> Have you been in the bottle again? 
> If this is not a joke, it is not funny. 
> 
> On Sat, 2 Sep 2000, Jeff V. Merkey wrote: 
> 
> > 
> > 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 majordomo@vger.kernel.org 
> > Please read the FAQ at http://www.tux.org/lkml/ 
> > 
> 
> Andre Hedrick 
> The Linux ATA/IDE guy 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Andre Hedrick (andre@linux-ide.org)
Date: Sun Sep 03 2000 - 00:42:15 EST 


Apology to Jeff, 


I am sorry to here of this, but I know what you mean about microsoft. 
My and co-worker's code for doing full taskfile access under linux was 
rejected here but is being used in MicroSoft Whistler 2001. They are 
quick to grab the very best of Linux and adopt it for their own. 


Yes when it gets down to it, life is the only thing of value. 


Please enjoy yours, and I will offer the first hand to welcome you back 
regardless. I mean that too!! 


As you know, I am one of the violently flamed and flaming person on the 
list and as a developer. I will fight at the drop of a hat or not, 
regardless. We had our differences, but that was then. 


I am sure that there will be other developers like myself that will NDA 
with you to get "NDS Project/NTFS/M2FS" in to linux and will test with 
you on the outside until. 


Follow up offline..... 


Respectfully, 


On Sat, 2 Sep 2000, Jeff V. Merkey wrote: 


> 
> Andre, 
> 
> One of our best friends we've known for years tried to kill himself when 
> Novell layed him off. I will reconsider later, but not now. Not with 
> what's going on at Novell. If we post it, Microsoft will grab it and it 
> will be in NT within 48 hours of them downloading it from our site. 
> Linux, NT, NetWare, NWFS, NDS, cars, houses, money -- these are all 
> things, and things can be replaced. Lives cannot. Linux can wait a few 
> months until the dust settles at Novell. 
> 
> We also spend too much debugging other peoples buggy code in Linux and 
> our own buggy code with printk() and kdb. A lot of the types of 
> problems we see, like SMP memory corruption are impossible to debug with 
> KDB. I've given Linus the code for a killer kernel debugger, but he has 
> not shown any proactive interest in wanting to leverage it. I am 
> spending 4X the $$$ paying engineers than I should. Example: NWFS on 
> NT took four months to develop and productize. I have been working on 
> NWFS on Linux for 18 months, and still not all the issues are resolved. 
> A kernel debugger would make all our lives easier and cost me less money 
> in salaries to engineers for particular projects. 
> 
> Jeff 
> 
> Andre Hedrick wrote: 
> > 
> > Jeff, 
> > 
> > Have you been in the bottle again? 
> > If this is not a joke, it is not funny. 
> > 
> > On Sat, 2 Sep 2000, Jeff V. Merkey wrote: 
> > 
> > > 
> > > 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 majordomo@vger.kernel.org 
> > > Please read the FAQ at http://www.tux.org/lkml/ 
> > > 
> > 
> > Andre Hedrick 
> > The Linux ATA/IDE guy 
> 


Andre Hedrick 
The Linux ATA/IDE guy 



- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Henning P. Schmiedehausen (hps@tanstaafl.de)
Date: Sun Sep 03 2000 - 12:18:46 EST 


andre@linux-ide.org (Andre Hedrick) writes: 



>Apology to Jeff, 


>I am sorry to here of this, but I know what you mean about microsoft. 
>My and co-worker's code for doing full taskfile access under linux was 
>rejected here but is being used in MicroSoft Whistler 2001. They are 
>quick to grab the very best of Linux and adopt it for their own. 


If you can prove this, then you could talk to FSF about M$ GPL 
violations. 


Regards 
Henning 


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Andre Hedrick (andre@linux-ide.org)
Date: Sun Sep 03 2000 - 15:19:38 EST 


On 3 Sep 2000, Henning P. Schmiedehausen wrote: 


> andre@linux-ide.org (Andre Hedrick) writes: 
> 
> 
> >Apology to Jeff, 
> 
> >I am sorry to here of this, but I know what you mean about microsoft. 
> >My and co-worker's code for doing full taskfile access under linux was 
> >rejected here but is being used in MicroSoft Whistler 2001. They are 
> >quick to grab the very best of Linux and adopt it for their own. 
> 
> If you can prove this, then you could talk to FSF about M$ GPL 
> violations. 


You can not go after people for patches. 
Linux rejected the code because it does not understand nor does anyone 
have the desire to learn what it does. Since it is not in the kernel 
there is no GPL issue. Upon Microsoft's adpotion of the model they will 
be years ahead of Linux. FreeBSD does something similar and I expect them 
to soon to begin laughing at us for being stupid. 


Basically I do not care, because Linux does not care. 


The things lost and stagnating development is that I can not do new 
features without the code. Some of the newest features in Linux like 
auto_crc_downgrade is being adopted by Intel and a future hardware IO 
access that will allow for sideways disk access will convert the software 
into hardware. 


The future of IO-MEM mapped for ATA to allow for PRD sliding or zero-copy. 
This and a bunch of other tricks are dependent of having a clean native 
taskfile. 


Cheers, 


Andre Hedrick 
The Linux ATA/IDE guy 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Sun Sep 03 2000 - 16:35:59 EST 


> Linux rejected the code because it does not understand nor does anyone 
> have the desire to learn what it does. Since it is not in the kernel 
> there is no GPL issue. Upon Microsoft's adpotion of the model they will 


If its your code there isnt anyway. You can license it to multiple people 
in general. And why not. 


> The things lost and stagnating development is that I can not do new 
> features without the code. Some of the newest features in Linux like 
> auto_crc_downgrade is being adopted by Intel and a future hardware IO 
> access that will allow for sideways disk access will convert the software 
> into hardware. 


You don't play with the mainstream IDE code while you are stabilizing a release 
you do it for 2.5 - sometimes things just miss deadlines. 


Alan 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Sun Sep 03 2000 - 23:01:56 EST 


Andre wrote: 


> Linux rejected the code because it does not understand nor does anyone 
> have the desire to learn what it does. Since it is not in the kernel 
> there is no GPL issue. Upon Microsoft's adpotion of the model they will 


That's B.S. The GPL is a Copyright license; it applies whether or not 
it is in the kernel. Microsoft (or anyone else for that matter) can't 
take your code and use it without consent. The GPL is one way of giving 
consent, with certain strings attached. 


- Ted 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: David S. Miller (davem@redhat.com)
Date: Mon Sep 04 2000 - 19:04:09 EST 


Date: Sat, 02 Sep 2000 15:58:50 -0600 
From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 


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 
davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Mon Sep 04 2000 - 19:13:51 EST 


> 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 majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 05:49:39 EST 


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 majordomo@vger.kernel.org 
> 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 majordomo@vger.kernel.org 
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 (mingo@elte.hu)
Date: Tue Sep 05 2000 - 06:13:08 EST 


On Tue, 5 Sep 2000, Alan Cox wrote: 


> I spend my time thinking. But I prefer to spend it thinking about the 
> bug not about finding it and how long fsck takes. [...] 


if we only optimize for the debugging time spent by seasoned kernel 
developers then you are completely right. But if we optimize for new 
kernel developers learning the right methodology, and if we optimize for 
the *development* process (not the *release* process) of the kernel then 
reducing the amount of debugging functionality is the right choice. 


> 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 


IMO there was only one historically hard spinlock-related problem that 
needed solving, this is the 'locks up hard' problem (which is solved). The 
rest was never really an debugging obstacle, 99% of the spinlock related 
bugs manifest themselves in clear, unambiguous lockups. 


there is another type of bug that is tough to find without an automatic 
tool - memory leaks. 


I dont think there is any other systematic bug (besides hard lockups and 
memory leaks) that occur often and can only be effectively found via 
debugging tools. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jes Sorensen (jes@linuxcare.com)
Date: Tue Sep 05 2000 - 13:01:20 EST 


>>>>> "Jeff" == Jeff V Merkey <jmerkey@timpanogas.com> writes: 


Jeff> Ingo Molnar wrote: 


>> you dont contribute a bit to the generic kernel and the kernel 
>> infrastructure itself. 


Jeff> I contribute code, time, and $$$, Ingo. 


HAve you contributed code to anything but your own private project 
which you have just declared to be withdrawn so you can go stick it 
into your own custom OS? I don't remember seeing you contribute code 
to any other part of the kernel, besides scream about bugs in the 
kernel that shows up to be bugs in your compiler etc. 


Jes 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 13:11:41 EST 


All the stuff on our website and ftp servers is free Linux code and it 
runs in the kernel. Novell's customers have been downloading it for 
over a year. At any point, Linux is free to take it and use it. Lots 
of Linux users already are. 


Jeff 


Jes Sorensen wrote: 
> 
> >>>>> "Jeff" == Jeff V Merkey <jmerkey@timpanogas.com> writes: 
> 
> Jeff> Ingo Molnar wrote: 
> 
> >> you dont contribute a bit to the generic kernel and the kernel 
> >> infrastructure itself. 
> 
> Jeff> I contribute code, time, and $$$, Ingo. 
> 
> HAve you contributed code to anything but your own private project 
> which you have just declared to be withdrawn so you can go stick it 
> into your own custom OS? I don't remember seeing you contribute code 
> to any other part of the kernel, besides scream about bugs in the 
> kernel that shows up to be bugs in your compiler etc. 
> 
> Jes 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Tue Sep 05 2000 - 13:32:18 EST 


> IMO there was only one historically hard spinlock-related problem that 
> needed solving, this is the 'locks up hard' problem (which is solved). The 
> rest was never really an debugging obstacle, 99% of the spinlock related 
> bugs manifest themselves in clear, unambiguous lockups. 


Then why are we still finding obscure lock ordering bugs in 2.2 ? Finding them 
when they bite you is easy, finding the obscure ones when they dont generally 
bite is much harder - thats where debugging kernels that trap and dump 
lock lists for order violations are a big win 



- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 13:51:19 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> Jes Sorensen wrote: 


> > HAve you contributed code to anything but your own private project 
> > which you have just declared to be withdrawn so you can go stick it 
> > into your own custom OS? I don't remember seeing you contribute code 
> > to any other part of the kernel, besides scream about bugs in the 
> > kernel that shows up to be bugs in your compiler etc. 


> All the stuff on our website and ftp servers is free Linux code and it 
> runs in the kernel. [...] 


Jes's claim is true - i just checked it, none of the stuff on your FTP 
site contributes to anything but your own private project which you have 
just declared to be withdrawn so you can go stick it into your own custom 
OS. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 13:56:36 EST 


On Tue, 5 Sep 2000, Alan Cox wrote: 


> Then why are we still finding obscure lock ordering bugs in 2.2 ? 
> Finding them when they bite you is easy, finding the obscure ones when 
> they dont generally bite is much harder - thats where debugging 
> kernels that trap and dump lock lists for order violations are a big 
> win 


i stand corrected - lock ordering indeed is a problem, although i think 
2.4 is much cleaner in this regard, we have less lock hierarchies, mainly 
due to getting rid of much of the BKL. 


i think another, natural debugging help here will be to make the UP kernel 
preemptibe in 2.5. That will simulate most of the SMP locking scenarios on 
UP as well, and we have much more UP users than SMP users. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 15:27:45 EST 


Amen Brother. 


Alan Cox wrote: 
> 
> > IMO there was only one historically hard spinlock-related problem that 
> > needed solving, this is the 'locks up hard' problem (which is solved). The 
> > rest was never really an debugging obstacle, 99% of the spinlock related 
> > bugs manifest themselves in clear, unambiguous lockups. 
> 
> Then why are we still finding obscure lock ordering bugs in 2.2 ? Finding them 
> when they bite you is easy, finding the obscure ones when they dont generally 
> bite is much harder - thats where debugging kernels that trap and dump 
> lock lists for order violations are a big win 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Andi Kleen (ak@suse.de)
Date: Tue Sep 05 2000 - 05:20:31 EST 


> 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 majordomo@vger.kernel.org 
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 (mingo@elte.hu)
Date: Tue Sep 05 2000 - 06:03:49 EST 


On Tue, 5 Sep 2000, Andi Kleen wrote: 


> 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. [...] 


this is the conceptual difference David tried to show, and which view i 
support as well. There are two basic types of 'debugging behaviors': 


A) 'Collect enough data to understand the local context and fix the bug.' 


B) 'See the point of the immediate crash, think about that code, think 
about code that called this code, think about the intent and 
implementation of that code and find the bug based on 
understanding the code.' 


A) results in people being able to debug easy and moderate kernel bugs. 
The same people are lost if faced with bugs that are not apparent in the 
'state of the system around the bug' represented by the debugger. 


B) results in people with the ability to identify bugs based on the source 
code - and the ability to fix the really mindblowing tough bugs. We had 
about 10 such bugs during the cycle of the 2.3 kernel. 


I do claim that the real mainsteam-kernel development 'bottleneck' is the 
ability to fix the tough bugs. It's always these tough bugs that keep up 
the addition of new features in devel kernels. We should thus do 
everything to teach people the proper debugging methodology. 


A) takes less time for the easy bugs - it might also speed up driver 
development. But it is utterly useless for the really tough problems. We 
had really tough bugs in 2.3 that one couldnt find even with the heaviest 
hitting debugging equipment. Debugging code in the kernel also blurs the 
intention of the code, which makes B) harder. 


B) is a slower process to both learn and practice, but will also lead to 
more (unrelated) code improvements (based on better understanding of 
various kernel subsystems) and ultimately leads to better kernel 
developers. 


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. 


i have nothing against (in fact contributed to) independent debugging 
functionality like IKD / KDB. It's slightly more pain to keep it uptodate 
with the devel kernel, but the devel kernel itself must stay focused on 
the strategic goals, not the tactical ones. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Andi Kleen (ak@suse.de)
Date: Tue Sep 05 2000 - 06:04:32 EST 


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 majordomo@vger.kernel.org 
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 (mingo@elte.hu)
Date: Tue Sep 05 2000 - 06:22:55 EST 


On Tue, 5 Sep 2000, Andi Kleen wrote: 


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


well, they will sooner or later notice that it's easier to fix bugs by 
following the development of the kernel and understanding the underlying 
principles and the code. As elitist as it might seem, we rather need 10 
highly skilled developers who understand the kernel than 100 moderately 
skilled ones who know how to operate a kernel debugger and barely anything 
else. [this is not an insult towards people with less experience - having 
less experience is just a temporary stage of a process, nothing else. But 
if it becomes the end station thats a problem IMHO.] 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 06:21:05 EST 


Ingo Molnar wrote: 
> 
> On Tue, 5 Sep 2000, Andi Kleen wrote: 
> 
> > 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. 
> 
> well, they will sooner or later notice that it's easier to fix bugs by 
> following the development of the kernel and understanding the underlying 
> principles and the code. As elitist as it might seem, we rather need 10 
> highly skilled developers who understand the kernel than 100 moderately 
> skilled ones who know how to operate a kernel debugger and barely anything 
> else. [this is not an insult towards people with less experience - having 
> less experience is just a temporary stage of a process, nothing else. But 
> if it becomes the end station thats a problem IMHO.] 


A kernel debugger will reduce development costs. No one cares what's 
underneath, they just care about getting their stuff out the door and 
reducing the $$$ to support it. This whole argument is one of control 
and not of technical merit. I'm putting it out in MANOS and it's there 
for Linux. Linus can use it if he want's it. ALL of my developers and 
folks I deal with say this is a good idea. 


Jeff 


> 
> Ingo 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 06:45:45 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> A kernel debugger will reduce development costs. [...] 


... of Jeff V. Merkey - possibly. You are too much focused on your own 
needs, you dont contribute a bit to the generic kernel and the kernel 
infrastructure itself. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 06:43:42 EST 


Ingo Molnar wrote: 
> 
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> 
> > A kernel debugger will reduce development costs. [...] 
> 
> ... of Jeff V. Merkey - possibly. You are too much focused on your own 
> needs, you dont contribute a bit to the generic kernel and the kernel 
> infrastructure itself. 
> 


Why do young kids always get personal all the time? This is not 
personal, it's just $$$. 


Jeff 



> Ingo 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 06:45:44 EST 


Ingo Molnar wrote: 


you dont contribute a bit to the generic kernel and the kernel 
> infrastructure itself. 
> 


I contribute code, time, and $$$, Ingo. 


Jeff 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 10:30:46 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> A kernel debugger will reduce development costs. No one cares what's 
> underneath, [...] 


this is the point where IMO your argument gets flawed, and where you are 
apparently ignoring our arguments. With utmost respect, we *do* care about 
what's underneath. The health of what's underneath fueled and fuels the 
growth of Linux. I'd like to repeat it again: we cannot optimize for both 
the speed of FS driver development (your goal - correct me if i got it 
wrong), and long term health of the kernel proper itself (our goal), 
because in some areas (such as the inclusion of high complexity debugging 
facilities) they do contradict. (mostly they dont contradict) Long term 
health has priority - i cannot put it any simpler for you. Anyone who 
thinks driver development is the most important for Linux then thats a 
pretty shortsighted view IMO. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 13:06:58 EST 


Ingo Molnar wrote: 
> 
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> 
> > A kernel debugger will reduce development costs. No one cares what's 
> > underneath, [...] 
> 
> this is the point where IMO your argument gets flawed, and where you are 
> apparently ignoring our arguments. With utmost respect, we *do* care about 
> what's underneath. The health of what's underneath fueled and fuels the 
> growth of Linux. I'd like to repeat it again: we cannot optimize for both 
> the speed of FS driver development (your goal - correct me if i got it 
> wrong), and long term health of the kernel proper itself (our goal), 
> because in some areas (such as the inclusion of high complexity debugging 
> facilities) they do contradict. (mostly they dont contradict) Long term 
> health has priority - i cannot put it any simpler for you. Anyone who 
> thinks driver development is the most important for Linux then thats a 
> pretty shortsighted view IMO. 
> 


Ingo, 


I think the disconnect for you here is that you assume the Linux world 
will remain constant and that everything must look like unix to be 
good. In NetWare, susbsytems that are user space in Linux are in-kernel 
in NetWare for speed. NDS is a good example. NCP is another, routing is 
another. I am moving this stuff in-kernel to replicate NetWare's 
performance -- debugging an in-kernel NDS with "code reviews" will take 
forever. Just because Linux puts everything in user space does not mean 
that's how the whole world should be. There's a lot of kernel 
development I'm sure folks want to do with Linux they cannot because it 
too tough to debug. SMP problems I've run into on Linux with just take 
too long without these types of tools. THis is simple issue. I told 
Darren Major, Drew Major's brother, folks comments this morning against 
a kernel debugger in Linux -- he shook his head and said "how stupid can 
they be?" Enough said. 


Jeff 



> Ingo 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 13:22:23 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> I think the disconnect for you here is that you assume the Linux world 
> will remain constant [...] 


> [...] Just because Linux puts everything in user space does not mean 
> that's how the whole world should be. There's a lot of kernel 
> development I'm sure folks want to do with Linux they cannot because 
> it too tough to debug. SMP problems I've run into on Linux with just 
> take too long without these types of tools. [...] 


like a webserver? 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 13:15:52 EST 


Ingo Molnar wrote: 
> 
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> 
> > I think the disconnect for you here is that you assume the Linux world 
> > will remain constant [...] 
> 
> > [...] Just because Linux puts everything in user space does not mean 
> > that's how the whole world should be. There's a lot of kernel 
> > development I'm sure folks want to do with Linux they cannot because 
> > it too tough to debug. SMP problems I've run into on Linux with just 
> > take too long without these types of tools. [...] 
> 
> like a webserver? 


In NetWare, the webserver does run in-kernel. It's got the highest 
numbers for any web server on the planet on Intel. Visit 
www.novell.com. I don't plan to put the MANOS webserver in-kernel, BTW, 
but I mention this in anwswer to your question. Microsoft's web server 
appears to run in user space, but in fact, does not, BTW -- they have 
half of it down in-kernel as well for performance. 


Jeff 


Jeff 


> 
> Ingo 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 13:39:50 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> > > I think the disconnect for you here is that you assume the Linux world 
> > > will remain constant [...] 
> > 
> > > [...] Just because Linux puts everything in user space does not mean 
> > > that's how the whole world should be. There's a lot of kernel 
> > > development I'm sure folks want to do with Linux they cannot because 
> > > it too tough to debug. SMP problems I've run into on Linux with just 
> > > take too long without these types of tools. [...] 
> > 
> > like a webserver? 
> 
> In NetWare, the webserver does run in-kernel. It's got the highest 
> numbers for any web server on the planet on Intel. [...] 


while this probably it isnt exactly modest, i'd like to direct your 
attention to the following SPEC benchmarks: 


http://www.spec.org/osg/web99/results/res2000q2/ 


I cannot see any NetWare (or UnixWare) numbers there. Check out the 'TUX' 
webserver at: 


http://www.redhat.com/~mingo/TUX-patches/ 


which is an in-kernel webserver. So above you say TUX cannot exist because 
it's too tough to debug and because "The entire Linux Network subsystem 
needs an overhaul"? Why dont you actually let people decide wether they 
want to apply the KDB patch for kernel development? 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Richard Gooch (rgooch@ras.ucalgary.ca)
Date: Tue Sep 05 2000 - 16:21:16 EST 


Ingo Molnar writes: 
> 
> On Tue, 5 Sep 2000, Andi Kleen wrote: 
> 
> > 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. 
> 
> well, they will sooner or later notice that it's easier to fix bugs 
> by following the development of the kernel and understanding the 
> underlying principles and the code. As elitist as it might seem, we 
> rather need 10 highly skilled developers who understand the kernel 
> than 100 moderately skilled ones who know how to operate a kernel 
> debugger and barely anything else. [this is not an insult towards 
> people with less experience - having less experience is just a 
> temporary stage of a process, nothing else. But if it becomes the 
> end station thats a problem IMHO.] 


I think there's a certain amount of wishful thinking here. As you say, 
everyone has to start from nothing. But if the learning/development 
curve is too steep, or the process is too frustrating, you are going 
to lose a proportion of the potential gurus. You can't push people in 
a direction they don't want to go. Even a smart person can give up if 
something seems unnecessarily cumbersome. After all, they have other 
things to do as well besides kernel debugging. From what I've seen, 
most of the active developers are chronically overworked. Many 
projects compete for your attention. Why hit your head against a 
purposely erected brick wall? 


Social engineering is harder than you think ;-) 


Regards, 


Richard.... 
Permanent: rgooch@atnf.csiro.au 
Current: rgooch@ras.ucalgary.ca 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Ingo Molnar (mingo@elte.hu)
Date: Tue Sep 05 2000 - 17:28:09 EST 


On Tue, 5 Sep 2000, Richard Gooch wrote: 


> everyone has to start from nothing. But if the learning/development 
> curve is too steep, or the process is too frustrating, you are going 
> to lose a proportion of the potential gurus. You can't push people in 
> a direction they don't want to go. [...] 


nobody wants to force anything on anyone - you are free to apply KDB and 
the other debugging patches. But we can certainly help the usage of the 
right kind of debugging methodology. 


> [...] From what I've seen, most of the 
> active developers are chronically overworked. Many projects compete 
> for your attention. Why hit your head against a purposely erected 
> brick wall? 


active developers certainly have the skills to apply debugging facilities 
they need. The reference kernel should be IMO 'untainted' though. Believe 
me, during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc 
debugging code beyond recognition - eg. automatic checksumming of every 
physical page in the system to detect stray DMA related memory corruption. 
No rocket science, but ugly enough to 'taint' the kernel proper. Would any 
of the debugging facilities advocated in this thread have helped in the 
bugs we were chasing at that time? Nope. Do i want such debugging code to 
ever show up in the mainsteam kernel? Hell no. 


you dont want to carry a whole car-construction factory along with you 
when you are rally-racing. You probably want to carry a spare tire and a 
mobile phone - anything else would be a slowdown. 


Ingo 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: David S. Miller (davem@redhat.com)
Date: Tue Sep 05 2000 - 17:43:51 EST 


Date: Tue, 05 Sep 2000 12:15:52 -0600 
From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 


It's got the highest numbers for any web server on the planet on 
Intel. 


What is your metric for this claim? Last I checked Linux held the 
record for the current version of specweb, specweb99. 


Maybe Netware held some old specweb record with the specweb96 version 
of that benchmark, which is %100 static content whereas specweb99 is 
part static part dynamic content. 


I have just checked and in fact I do not see any SpecWeb99 submitted 
results which use NetWare as the OS. 


Later, 
David S. Miller 
davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Kurt Roeckx (Q@ping.be)
Date: Tue Sep 05 2000 - 17:59:02 EST 


On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote: 
> 
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> 
> > A kernel debugger will reduce development costs. No one cares what's 
> > underneath, [...] 
> 
> this is the point where IMO your argument gets flawed, and where you are 
> apparently ignoring our arguments. With utmost respect, we *do* care about 
> what's underneath. The health of what's underneath fueled and fuels the 
> growth of Linux. I'd like to repeat it again: we cannot optimize for both 
> the speed of FS driver development (your goal - correct me if i got it 
> wrong), and long term health of the kernel proper itself (our goal), 
> because in some areas (such as the inclusion of high complexity debugging 
> facilities) they do contradict. (mostly they dont contradict) Long term 
> health has priority - i cannot put it any simpler for you. Anyone who 
> thinks driver development is the most important for Linux then thats a 
> pretty shortsighted view IMO. 


A (better?) kernel debugger could help (certain) people to help improve 
the long term health, because they can't (or don't want) to use what's 
available, or just think they can't easely do it with them. It could help 
certain people who are used to debug a problem in certain ways, to debug 
it, where they have no idea how to do it with the current tools, because 
nobody explained them how to use them for that problem. 


That debugger shouldn't be part of the main kernel, specially if it's so 
complex. Trying to get the debugger to work might even find problems you 
wouldn't easely find otherwise. 



Kurt 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 18:08:03 EST 


David, 


Go visit their website and review the materials directy -- these are 
their claims -- not mine. It's www.novell.com. 


"David S. Miller" wrote: 
> 
> Date: Tue, 05 Sep 2000 12:15:52 -0600 
> From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 
> 
> It's got the highest numbers for any web server on the planet on 
> Intel. 
> 
> What is your metric for this claim? Last I checked Linux held the 
> record for the current version of specweb, specweb99. 
> 
> Maybe Netware held some old specweb record with the specweb96 version 
> of that benchmark, which is %100 static content whereas specweb99 is 
> part static part dynamic content. 
> 
> I have just checked and in fact I do not see any SpecWeb99 submitted 
> results which use NetWare as the OS. 
> 
> Later, 
> David S. Miller 
> davem@redhat.com 
> - 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
> the body of a message to majordomo@vger.kernel.org 
> Please read the FAQ at http://www.tux.org/lkml/ 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: David S. Miller (davem@redhat.com)
Date: Tue Sep 05 2000 - 18:13:00 EST 


Date: Tue, 05 Sep 2000 17:08:03 -0600 
From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 


Go visit their website and review the materials directy -- these 
are their claims -- not mine. It's www.novell.com. 


Ummm... circa April 15th, 1998 ;-))) 


Later, 
David S. Miller 
davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Linux/MANOS Kernel Debugger
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 18:20:53 EST 


I have written four OS's in my life (SAM, NetWare SMP, Wolf Mountain, 
MANOS). In each I always developed components in this order: 


1. Debugger 
2. Kernel 
3. Memory Manager 
4. I/O Subsystem. 


I always would write a debugger first that would run in kernel mode. 
You need a special polling keyboard driver and a raw screen memory 
interface that's self contained and not dependent on the kernel in any 
way. On Intel, I would always use a task gate interface for the 
exception handlers since this allows you to debug a trashed stack. If 
someone trashes the stack, and you get a page fault, if there are not 
task gates over the exceptions, it results in a double fault (which 
turns into a triple fault when the double fault exception gets hit with 
a trashed stack and reboots). 


To do this in Linux is very simple. Hook the exception handlers with 
task gates, create a TSS pool of free task gates, point the entry points 
into the MANOS debugger, (except the NMI gate -- it can be an interrupt 
gate since NMI interrrupts are prohibited by the hardware from ever 
nesting), and implement the task switch code in STARTUP.386 in MANOS as 
the gate entry stubs. Then the entire debugger could be moved en 
masse. At present, I decode CODEVIEW and NT symbols, but you will also 
notice that COFF symbol is also present in the debugger code -- the 
helper functions just need to be plugged. The entire debugger uses 
pluggable commands, register decodes, etc. and is easily moved to other 
processors than IA32. In fact, the IA32 disassembler in MANOS comes 
right out of GDB. 


Since NMI's are not nested, I use the NMI xcall interrupt on the APICs 
to perform TLB shootdowns since an NMI will always cut through running 
code and reload CR3 on IA32. I also use the NMI interrupt to break into 
other processors to debug them -- a very useful feature for a processor 
hung in a loop. 


There are special spin locks for the MANOS debugger -- it's fully SMP 
and can debug complex deadlocks and lock ordering. MANOS implements 
true sleep locks and has facilities for this, as well as semaphores. 


I think it would not be hard to put this in. My problem is time and 
"debugging the debugger" in Linux. The codes at our site and anyone who 
wants to put it in is welcome to. 


Also, MANOS is a Linux variant, so at any point, if Linus wants to "fire 
me" from it after it's posted and him and Alan take it over, be my 
guest. 


:-) 


Jeff 






Kurt Roeckx wrote: 
> 
> On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote: 
> > 
> > On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> > 
> > > A kernel debugger will reduce development costs. No one cares what's 
> > > underneath, [...] 
> > 
> > this is the point where IMO your argument gets flawed, and where you are 
> > apparently ignoring our arguments. With utmost respect, we *do* care about 
> > what's underneath. The health of what's underneath fueled and fuels the 
> > growth of Linux. I'd like to repeat it again: we cannot optimize for both 
> > the speed of FS driver development (your goal - correct me if i got it 
> > wrong), and long term health of the kernel proper itself (our goal), 
> > because in some areas (such as the inclusion of high complexity debugging 
> > facilities) they do contradict. (mostly they dont contradict) Long term 
> > health has priority - i cannot put it any simpler for you. Anyone who 
> > thinks driver development is the most important for Linux then thats a 
> > pretty shortsighted view IMO. 
> 
> A (better?) kernel debugger could help (certain) people to help improve 
> the long term health, because they can't (or don't want) to use what's 
> available, or just think they can't easely do it with them. It could help 
> certain people who are used to debug a problem in certain ways, to debug 
> it, where they have no idea how to do it with the current tools, because 
> nobody explained them how to use them for that problem. 
> 
> That debugger shouldn't be part of the main kernel, specially if it's so 
> complex. Trying to get the debugger to work might even find problems you 
> wouldn't easely find otherwise. 
> 
> Kurt 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 18:29:10 EST 


"David S. Miller" wrote: 
> 
> Date: Tue, 05 Sep 2000 17:08:03 -0600 
> From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 
> 
> Go visit their website and review the materials directy -- these 
> are their claims -- not mine. It's www.novell.com. 
> 
> Ummm... circa April 15th, 1998 ;-))) 


They've got some newer stuff. The best way to get the latest numbers 
would be to call Craig Miller 801-861-7000 (cmiller@novell.com), Dana 
Henriksen (dhenriks@novell.com), same # or Drew Major, Darren's brother, 
same # (rdmajor@novell.com). Drew will have the latest numbers for 
certain since he wrote the Web Server on NetWare, but both Craig and 
Dana are the guys to talk to about NetWare and could get them. Dana is 
the maintainer and principal architect of NetWare and knows more about 
it than anyone except Drew and Darren. 


:-) 


Jeff 


> 
> Later, 
> David S. Miller 
> davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
From: David S. Miller (davem@redhat.com)
Date: Tue Sep 05 2000 - 18:32:42 EST 


Date: Tue, 05 Sep 2000 17:29:10 -0600 
From: "Jeff V. Merkey" <jmerkey@timpanogas.com> 


"David S. Miller" wrote: 
> Ummm... circa April 15th, 1998 ;-))) 


They've got some newer stuff. The best way to get the latest numbers 
would be to call Craig Miller 801-861-7000 (cmiller@novell.com), Dana 
Henriksen (dhenriks@novell.com), same # or Drew Major, Darren's brother, 
same # (rdmajor@novell.com). 


This was an amusing progression: 


1) Novell has the best web benchmark numbers 


2) Oops, I didn't say that, Novell is, go see www.novell.com 


3) Oops, that's from nearly 2 years ago, go talk to the engineers 
they have the latest numbers certainly. 


I have to be honest and say that I can't take you seriously anymore. 


As usual, numbers talk bullshit walks, and when Novell makes some 
more up to date specweb submissions, I'll have a look, but until 
then it's hot air as far as I'm concerned. 


Later, 
David S. Miller 
davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: Linux/MANOS Kernel Debugger
From: Andi Kleen (ak@suse.de)
Date: Tue Sep 05 2000 - 18:34:37 EST 


On Tue, Sep 05, 2000 at 05:20:53PM -0600, Jeff V. Merkey wrote: 
> I think it would not be hard to put this in. My problem is time and 
> "debugging the debugger" in Linux. The codes at our site and anyone who 
> wants to put it in is welcome to. 


I looked at the Manos code and it seems to require a functional file system 
to read the source code during debugging. When the kernel is stopped 
in the debugger it is definitely not safe to access anything like a file 
system in Linux (e.g. due to locking issues) 


Without accessing the file system the debugger couldn't 
do much more than assembly level debugging like KDB, which already works 
fine. Precaching source is not practical. Developing a separate independent 
file system module that works safely even from a stopped kernel (and would 
still be functional enough so that you can compile and edit files on it) 
would also be major work. I guess Manos solved it by using DOS for that, 
but this is simply not possible in Linux. 


The only sane way to do source level kernel debugging IMHO is to do 
it from a second machine (sane =~ without being in deadlock country), which 
also already works nicely using remote gdb + kgdb stub. 



-Andi 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: Linux/MANOS Kernel Debugger
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Tue Sep 05 2000 - 18:40:07 EST 


Actually, the solution I think would be to use the MSDOS loader to boot 
linux. I will look at grabbing the ELF code in Linux and loading Linux 
from MSDOS -- if this can be accomplished you're there -- with an added 
benfit. When I am debugging MANOS, the source files and OS actually 
load from another NetWare server over a DOS connection (pretty slick) so 
in my setup the files are always remote, though they could just as well 
reside on a local fat partiton. Having DOS resident underneath gives 
you all kinds of cool stuff you can do (you will note that while MANOS 
is active in memory, DOS is still resident underneath and accessible). 


Perhaps the way to do this unobtrusively would be a different loader for 
Linux (a DOS loader) that will run the debugger underneath. The 
debugger in MANOS is self contained, and you will note has few 
dependencies on the OS code of any kind -- it was developed this way 
intentionally. We just take the MANOS loader, rip out the kernel, load 
Linux from LLOADER.386, and the debugger is there! 


Jeff 




Andi Kleen wrote: 
> 
> On Tue, Sep 05, 2000 at 05:20:53PM -0600, Jeff V. Merkey wrote: 
> > I think it would not be hard to put this in. My problem is time and 
> > "debugging the debugger" in Linux. The codes at our site and anyone who 
> > wants to put it in is welcome to. 
> 
> I looked at the Manos code and it seems to require a functional file system 
> to read the source code during debugging. When the kernel is stopped 
> in the debugger it is definitely not safe to access anything like a file 
> system in Linux (e.g. due to locking issues) 
> 
> Without accessing the file system the debugger couldn't 
> do much more than assembly level debugging like KDB, which already works 
> fine. Precaching source is not practical. Developing a separate independent 
> file system module that works safely even from a stopped kernel (and would 
> still be functional enough so that you can compile and edit files on it) 
> would also be major work. I guess Manos solved it by using DOS for that, 
> but this is simply not possible in Linux. 
> 
> The only sane way to do source level kernel debugging IMHO is to do 
> it from a second machine (sane =~ without being in deadlock country), which 
> also already works nicely using remote gdb + kgdb stub. 
> 
> -Andi 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Richard Gooch (rgooch@ras.ucalgary.ca)
Date: Tue Sep 05 2000 - 19:20:10 EST 


Ingo Molnar writes: 
> 
> On Tue, 5 Sep 2000, Richard Gooch wrote: 
> 
> > everyone has to start from nothing. But if the learning/development 
> > curve is too steep, or the process is too frustrating, you are going 
> > to lose a proportion of the potential gurus. You can't push people in 
> > a direction they don't want to go. [...] 
> 
> nobody wants to force anything on anyone - you are free to apply KDB 
> and the other debugging patches. But we can certainly help the usage 
> of the right kind of debugging methodology. 


You might think you're encouraging people to think instead of 
monkey-tap, but consider the people you're putting off. It's the other 
side of that coin. 


> > [...] From what I've seen, most of the 
> > active developers are chronically overworked. Many projects compete 
> > for your attention. Why hit your head against a purposely erected 
> > brick wall? 
> 
> active developers certainly have the skills to apply debugging 
> facilities they need. 


It's not just the skills. It's the time and energy. It's more effort, 
because you have to download it (and hope it's current and kernel 
drift hasn't rooted it), and you have to maintain more kernel trees 
(otherwise you send out patches with IKD mistakenly included (and 
don't tell me it doesn't happen, even by the most esteemed 
developers)). 


Skilled people are usually busy people (they have their fingers in too 
many pies). While they are better able to download and apply IKD, by 
the same token they are less inclined to, because they are busy, and 
besides, they know that they *shouldn't have to*. 


> The reference kernel should be IMO 'untainted' though. Believe me, 
> during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc 
> debugging code beyond recognition - eg. automatic checksumming of 
> every physical page in the system to detect stray DMA related memory 
> corruption. No rocket science, but ugly enough to 'taint' the 
> kernel proper. Would any of the debugging facilities advocated in 
> this thread have helped in the bugs we were chasing at that time? 
> Nope. Do i want such debugging code to ever show up in the mainsteam 
> kernel? Hell no. 


Would you classify IKD as a pile of warts you wouldn't want to see in 
the kernel? 


Surely there must be some useful features that can be included in the 
kernel without uglyfing it or slowing it down (configed out)? Leaving 
aside the social engineering attempts, of course :-) 


> you dont want to carry a whole car-construction factory along with 
> you when you are rally-racing. You probably want to carry a spare 
> tire and a mobile phone - anything else would be a slowdown. 


We're already carrying a small city. One extra factory won't 
hurt. It's just source bloat, not object or data bloat. 


Regards, 


Richard.... 
Permanent: rgooch@atnf.csiro.au 
Current: rgooch@ras.ucalgary.ca 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Mike Galbraith (mikeg@weiden.de)
Date: Wed Sep 06 2000 - 00:44:16 EST 


On Tue, 5 Sep 2000, Richard Gooch wrote: 
> Ingo Molnar writes: 
> 
> > The reference kernel should be IMO 'untainted' though. Believe me, 
> > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc 
> > debugging code beyond recognition - eg. automatic checksumming of 
> > every physical page in the system to detect stray DMA related memory 
> > corruption. No rocket science, but ugly enough to 'taint' the 
> > kernel proper. Would any of the debugging facilities advocated in 
> > this thread have helped in the bugs we were chasing at that time? 
> > Nope. Do i want such debugging code to ever show up in the mainsteam 
> > kernel? Hell no. 
> 
> Would you classify IKD as a pile of warts you wouldn't want to see in 
> the kernel? 


I run IKD 99.99% of the time (maintenance helper bee). Still, I wouldn't 
want to see it in the kernel.. except maybe kdb. IKD is very intrusive 
from the code readability standpoint. Memleak in particular has a zillion 
ugly ifdefs I don't know how to get rid of. 


> Surely there must be some useful features that can be included in the 
> kernel without uglyfing it or slowing it down (configed out)? Leaving 
> aside the social engineering attempts, of course :-) 


They can all be configured out, and they are all useful. KDB is the only 
one which (imho) could be integrated without uglifying the code. 


-Mike 


(What means 'social engineering attempts'?) 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Richard Gooch (rgooch@ras.ucalgary.ca)
Date: Wed Sep 06 2000 - 00:55:07 EST 


Mike Galbraith writes: 
> On Tue, 5 Sep 2000, Richard Gooch wrote: 
> > Ingo Molnar writes: 
> > 
> > > The reference kernel should be IMO 'untainted' though. Believe me, 
> > > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc 
> > > debugging code beyond recognition - eg. automatic checksumming of 
> > > every physical page in the system to detect stray DMA related memory 
> > > corruption. No rocket science, but ugly enough to 'taint' the 
> > > kernel proper. Would any of the debugging facilities advocated in 
> > > this thread have helped in the bugs we were chasing at that time? 
> > > Nope. Do i want such debugging code to ever show up in the mainsteam 
> > > kernel? Hell no. 
> > 
> > Would you classify IKD as a pile of warts you wouldn't want to see in 
> > the kernel? 
> 
> I run IKD 99.99% of the time (maintenance helper bee). Still, I wouldn't 
> want to see it in the kernel.. except maybe kdb. IKD is very intrusive 
> from the code readability standpoint. Memleak in particular has a zillion 
> ugly ifdefs I don't know how to get rid of. 
> 
> > Surely there must be some useful features that can be included in the 
> > kernel without uglyfing it or slowing it down (configed out)? Leaving 
> > aside the social engineering attempts, of course :-) 
> 
> They can all be configured out, and they are all useful. KDB is the 
> only one which (imho) could be integrated without uglifying the 
> code. 


Fine. Then let's add that, at least. It's probably the #1 thing 
anyway. 


> (What means 'social engineering attempts'?) 


Attempting to change people's habits by making it hard to debug. 


Regards, 


Richard.... 
Permanent: rgooch@atnf.csiro.au 
Current: rgooch@ras.ucalgary.ca 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: David S. Miller (davem@redhat.com)
Date: Wed Sep 06 2000 - 00:55:11 EST 


Date: Tue, 5 Sep 2000 23:55:07 -0600 
From: Richard Gooch <rgooch@ras.ucalgary.ca> 


> (What means 'social engineering attempts'?) 


Attempting to change people's habits by making it hard to debug. 


Hard work now leads to less work later. 


Later, 
David S. Miller 
davem@redhat.com 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Damien Miller (djm@mindrot.org)
Date: Wed Sep 06 2000 - 05:36:08 EST 


On Tue, 5 Sep 2000, David S. Miller wrote: 


> > (What means 'social engineering attempts'?) 
> 
> Attempting to change people's habits by making it hard to debug. 
> 
> Hard work now leads to less work later. 


Lots of people (myself included) would like to be able to debug and 
generally hack the Linux kernel but cannot due to lack of time and the 
steep learning curve imposed by the lack of a debugger and good 
documentation. 


Not everyone has the time or resources to put in the "hard work" now. 


Tools like a KDB would make the kernel a lot more accessible to the 
time-poor. 


-d 



-- 
| ``The power of accurate observation is | Damien Miller <djm@mindrot.org>
| commonly called cynicism by those who | @Work <djm@ibs.com.au>
| have not got it'' - George Bernard Shaw | http://www.mindrot.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: Mike Galbraith (mikeg@weiden.de)
Date: Wed Sep 06 2000 - 10:58:10 EST 


On Wed, 6 Sep 2000, Damien Miller wrote: 


> On Tue, 5 Sep 2000, David S. Miller wrote: 
> 
> > > (What means 'social engineering attempts'?) 
> > 
> > Attempting to change people's habits by making it hard to debug. 
> > 
> > Hard work now leads to less work later. 
> 
> Lots of people (myself included) would like to be able to debug and 
> generally hack the Linux kernel but cannot due to lack of time and the 
> steep learning curve imposed by the lack of a debugger and good 
> documentation. 


Gdb stub has been available for quite some time, so the 'no debugger' 
argument doesn't fly ;-) The learning curve _is_ steep, but a debugger 
doesn't flatten it one bit. It's all that conceptual stuff that makes 
it so steep, and (drat) debuggers don't have a grok-concept command. 


> Not everyone has the time or resources to put in the "hard work" now. 
> 
> Tools like a KDB would make the kernel a lot more accessible to the 
> time-poor. 


Kdb is available to all. I think it should be _integrated_ mostly 
because of the (potential) improvement in bug report quality. 


If it _were_ integrated, more folks would be tempted to rummage around 
trying to solve problems by themselves. Having that resource at your 
disposal dares you to make an attempt.. and learn in the process. It 
encourages growth. 


-Mike (who now shuts his yap;) 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: Linux/MANOS Kernel Debugger
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Wed Sep 06 2000 - 11:00:01 EST 


"Jeff V. Merkey" wrote: 


Andi, 


I gave this considerable thought last night, and I have come to the 
conclusion that the only person who could put this into Linux as 
unobstrusively as possible is me, since I wrote it. I am looking at 2.4 
today, and I will start moving the code and striping down MANOS to 
prepare a patch. Xcalls will be ugly. I am told that I need to use 
diff -Naur file1 file2 since the last patches I submited used an older 
format. I will post the MANOS debugger patch for IA32 at 
vger.timpanogas.org next week before I go to NetWorld InterOp in 
Atlanta. Folks who want to port it to IA64 or other processors can 
download the code and repost changes and patches to list 
manos-kernel@vger.timpanogas.org (I am getting pretty good at running 
diff and patch now). The mailing list will be up next week. 


Anyone wanting to stone me for posting this thread is invited to come by 
Linux NetWorX booth at the show demoing a Distributed FIle System (M2FS) 
on Linux. Let him who is without sin cast the first stone. 


:-) 


Jeff 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: Linux/MANOS Kernel Debugger
From: Admin Mailing Lists (mlist@intergrafix.net)
Date: Thu Sep 07 2000 - 14:23:07 EST 


On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 


> 
> Actually, the solution I think would be to use the MSDOS loader to boot 
> linux. I will look at grabbing the ELF code in Linux and loading Linux 
> from MSDOS -- if this can be accomplished you're there -- with an added 
> benfit. When I am debugging MANOS, the source files and OS actually 
> load from another NetWare server over a DOS connection (pretty slick) so 
> in my setup the files are always remote, though they could just as well 
> reside on a local fat partiton. Having DOS resident underneath gives 
> you all kinds of cool stuff you can do (you will note that while MANOS 
> is active in memory, DOS is still resident underneath and accessible). 
> 
> Perhaps the way to do this unobtrusively would be a different loader for 
> Linux (a DOS loader) that will run the debugger underneath. The 
> debugger in MANOS is self contained, and you will note has few 
> dependencies on the OS code of any kind -- it was developed this way 
> intentionally. We just take the MANOS loader, rip out the kernel, load 
> Linux from LLOADER.386, and the debugger is there! 
> 


since you'd be using DOS, wouldn't you need a MS license then for every 
kernel debugger you put out there? 


-Cygnus 
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. 
Anthony J. Biacco Network Administrator/Engineer 
thelittleprince@asteroid-b612.org Intergrafix Internet Services 


"Dream as if you'll live forever, live as if you'll die today" 
http://www.asteroid-b612.org http://www.intergrafix.net 
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. 


- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/ 

Re: Linux/MANOS Kernel Debugger
From: Jeff V. Merkey (jmerkey@timpanogas.com)
Date: Thu Sep 07 2000 - 15:15:34 EST


Bryan Sparks at Lineo has given TRG an unlimited distribution license 
for DR-DOS which is what we will provide for the DOS loadable versions 
of MANOS freely from our website. Lineo also distributes free DR-DOS. 
At present, I am putting the MANOS debugger into Linux proper without 
DOS but ext2 instead. 


Jeff 


Admin Mailing Lists wrote: 
> 
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote: 
> 
> > 
> > Actually, the solution I think would be to use the MSDOS loader to boot 
> > linux. I will look at grabbing the ELF code in Linux and loading Linux 
> > from MSDOS -- if this can be accomplished you're there -- with an added 
> > benfit. When I am debugging MANOS, the source files and OS actually 
> > load from another NetWare server over a DOS connection (pretty slick) so 
> > in my setup the files are always remote, though they could just as well 
> > reside on a local fat partiton. Having DOS resident underneath gives 
> > you all kinds of cool stuff you can do (you will note that while MANOS 
> > is active in memory, DOS is still resident underneath and accessible). 
> > 
> > Perhaps the way to do this unobtrusively would be a different loader for 
> > Linux (a DOS loader) that will run the debugger underneath. The 
> > debugger in MANOS is self contained, and you will note has few 
> > dependencies on the OS code of any kind -- it was developed this way 
> > intentionally. We just take the MANOS loader, rip out the kernel, load 
> > Linux from LLOADER.386, and the debugger is there! 
> > 
> 
> since you'd be using DOS, wouldn't you need a MS license then for every 
> kernel debugger you put out there? 
> 
> -Cygnus 
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. 
> Anthony J. Biacco Network Administrator/Engineer 
> thelittleprince@asteroid-b612.org Intergrafix Internet Services 
> 
> "Dream as if you'll live forever, live as if you'll die today" 
> http://www.asteroid-b612.org http://www.intergrafix.net 
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
Please read the FAQ at http://www.tux.org/lkml/