Messages in this thread |  | | Date | Sat, 02 Sep 2000 16:16:47 -0600 | From | "Jeff V. Merkey" <> | Subject | 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |