> It sounds like you really need a private macro or private debugging
> code, not a modification to a function which nearly all kernel code
> calls at one time or another.
Take a look at my "patch #3" to see if it looks "better". It's not
calling any dangerous functions and it gives other advantages (lowever
console_lock contention... it might be better?
> I don't think too many people are going to favor changing printk to be
> optimal for "quick debugging checks"... which involve userland
> addresses and/or paging. printk should be optimal, sure, but this is
> NOT a case the core kernel needs to optimize for.
But my point all along is that it only addes a spin_lock and spin_unlock
on a very low contended lock (unless you're doing tons of printk's, in
which you would spin on the console_lock isntead) to the common
case. Only the uncommon case that you only hit durring debugging gets
effected...
> > I'll throw together a
> > new patch that will hopefully address some problems...
> What exactly are those problems?
Well, from the general kernel perspective there's a highly contended
console_lock that is having to be held through a vsprintf, and in my
perspective, deadlock is not happy. :)
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:11 EST