Messages in this thread |  | | | Date | Sun, 02 Jan 2005 23:44:03 -0500 | | From | Jim Nelson <> | | Subject | Re: printk loglevel policy? |
| |
Randy.Dunlap wrote: > Keith Owens wrote: > >> On Sun, 02 Jan 2005 13:41:34 -0800, "Randy.Dunlap" <rddunlap@osdl.org> >> wrote: >> >>> Jim Nelson wrote: >>> >>>> Or does printk() do some tracking that I didn't see as to where in >>>> the kernel the strings are coming from? >>> >>> >>> That kind of garbled output has been known to happen, but >>> the <console_sem> is supposed to prevent that (along with >>> zap_locks() in kernel/printk.c). >> >> >> >> Using multiple calls to printk to print a single line has always been >> subject to the possibility of interleaving on SMP. We just live with >> the risk. Printing a complete line in a single call to printk is >> protected by various locks. Print a line in multiple calls is not >> protected. If it bothers you that much, build up the line in a local >> buffer then call printk once. > > > True, I was thinking about the single line case, which I > have seen garbled/mixed in the past (on SMP). Hopefully > that one is fixed. >
Okay, that answered my question. Is is frowned upon to use strncat/strcat in the kernel? I have yet to see any use of them outside of the definition in lib/string.c. It would seem to be faster (less potential contention for the printk locks). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |