Date: Fri, 6 Oct 2000 05:22:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: tlambert@primenet.com (Terry Lambert), mark@grondar.za (Mark Murray), jburkhol@HOME.COM (Jake Burkholder), bp@butya.kz (Boris Popov), freebsd-smp@FreeBSD.ORG Subject: Re: Problems with kthread_exit() and SMPng Message-ID: <200010060522.WAA22938@usr02.primenet.com> In-Reply-To: <20001005151504.K27736@fw.wintelcom.net> from "Alfred Perlstein" at Oct 05, 2000 03:15:04 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> One of the options for fixing kernel logging under SMP was to have > a very simple queing mechanism to send the messages to a kernel > thread that would be repsoncible for the output. I followed that discussion when it was taking place. It makes sense that one would queue any IPC between any part of a kernel and the kernel thread that is responsible for serially processing the IPC request. So a more generic mechanism for queueing messages in the kernel is probably called for (you may rememebr my call for this back when you introduced your limited purpose API which did basically this type of queueuing). It makese sense to protect the queues with a mutex per queue, for the purposes of enqueueng and dequeueing these messages. > You see, the problem with logging is that the logging calls are in > a lot of weird places, nevermind critical ones like panic, there > needs to be a special relationship between the logging kthread and > the system which may be difficult to set up. I disagree with this completely. There does not need to be a "special relationship"; special relationships are anathema. Look at the special relationship between libkvm and kernel structures (a data interface, as you appear to be suggesting for logging), and the hell it hath wrought. As people continue to extend things rather than fixing old, broken things, this problem, and problems like it, will continue to haunt us. > You also have to take into account that the output method of > the driver might block therefore we need to hand off the > blocking to someone else. It is not permissable to block while holding a mutex; I've played this song before, and there's no need to repeat the whole thing in this thread. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010060522.WAA22938>