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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:14 EST