Date: Fri, 29 Jun 2007 18:17:09 +0800 From: "Howard Su" <howard0su@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: concept prove patch for ktrace output to all file types Message-ID: <f126fae00706290317qbd1e74aocaa482f56df842e9@mail.gmail.com> In-Reply-To: <20070628094219.W9286@fledge.watson.org> References: <f126fae00706270934h3e39e33avaa686aa2c12b72c6@mail.gmail.com> <20070628094219.W9286@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/28/07, Robert Watson <rwatson@freebsd.org> wrote: > > What happens to processes associated with the same or other ktrace > sessions if > one ktrace session stalls due to a fifo or pipe buffer filling? I don't think my patch will bring the new problem here. Original, we write to disk still be blocked due to some things like disk busy, etc. If my reading is right, ktrace use two way to submit request. ktr_enqueue will put the request into a queue if it is not safe to enter VFS. ktr_submitrequest will be used to commit record to disk immediately. in my case, blocking will be safe there. The issue about losting some recording to fifo blocking. I don't think we can solve that in the kernel. It is userland code's responsiblity to read it to avoid losting data. -- -Howard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f126fae00706290317qbd1e74aocaa482f56df842e9>