From nobody Mon Feb 07 16:40:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E84419B6C11; Mon, 7 Feb 2022 16:40:41 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JssMX6qNKz3Hdp; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=UW//J2e6EJPVioIyKNM19XdQNYfD7snsV35WAkh5HcqWrIHX0pKJ8x0/eYlEVM+Scs9gfn vkSNb754BbY+3Bnzggo0RMmX0BKzeblbEZUqMFktFE1Ifsp3He6023hqdnk486R7i2VzGq bCYoWzy2xHZFdvCxksq4FJgsj3YjMz8lVEHFkWQFkVty7uDYkZ4i3gjoCuuXJcpR25Y3hl XJ5VZcL73pHSrSp5fvFPYjwwhy2H0D1o0OEJXmkWtEn5ijDhfoEj4RKBg/d0pZjyz4mqsp /HZwOJnPQo3WW4isCqUERyb7ZCKRqyuA8vmXCHh+jGLRLibcHusB+OcpRX4m9g== Received: from [192.168.1.106] (host-173-212-73-28.public.eastlink.ca [173.212.73.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 9956B2E6B4; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Mon, 7 Feb 2022 12:40:39 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 From: Mitchell Horne Subject: Re: A new boot-time trace framework To: "Bjoern A. Zeeb" Cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org References: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Language: en-CA In-Reply-To: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=Ssi+58zxyS8AQjffHROJ7oVn3DKzQ/rJyCDDwsk35TJ87nvWWmUzYUSCzKg9sYMTASxy7g aUcWIcyCutrrJkq0k26NPbdEuKnKluor0LROB8VIGXKOy+hVWWqgmTtVf9GwO8+OgqEyRF HxbbUfO0Ft2mbFqqaBtaRg5L6963gmBjZQaElBwgueHv/EfCKSnvK+rF7LsZpmg6pmK1UI 2DvbAu+V2LJupuwRoVaESBJAzRyrGvdNvl/98uM8cCcyVqARMwSGIZ7Y3smNpRze8UVpjo YyjL90N0F5t6ZZ2Km5PQqxLkarK6uAqDvzPl7IrT+3v2G0Y5xkwBrf8s0X+Abg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644252041; a=rsa-sha256; cv=none; b=iNyTUWjgP1k7ZDRM/3fOrdnsuj6IqWuj/9unyW7HHYipNFiM/DsS6iqHxhZNz7yo+Gks1+ KZ4p5H/M9bdFwVn4QArk9Q/zqAfQzXspjjByHNmlH8OFAYY83HsqctXn3stzMMvz9e1Bcc aSZvjmx2yioDV0AujmCjvNeSpn3VORX9p6k1uSHQq61UMIDoK4RI66jyfxTma3bqL1Hsrm 4qaMmEc01vqY/WRW+EWO0Bnf53LVWkbxl+mFsgGtTZSn5oADyCQCiL1AFGoj9kyd5nAVux ClfTL14QROCIIR3QPIMfEFAqaGFOMdU2MmAdJY/iWbuWyJl0fdVt3IazOP63sQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/10/21 13:39, Bjoern A. Zeeb wrote: > On 10 Nov 2021, at 16:26, Mitchell Horne wrote: > >> Unlike TSLOG, I intend for this work to be compiled in to the kernel >> by default, but disabled behind a tunable (kern.boottrace.enabled). >> The cost of doing so should be minimal, only a couple of syscalls >> added to init(8) at most. > Hi, apologies for my delayed reply here. > I think if you really want to have this on by default (whether that make > sense or not for the majority of people) I’d at least avoid the function > call and reduce it to a branch which is super-easy to do. > Good suggestion, the latest version has this change. > My honest feeling is that another of the at least 3 other tracing > mechanisms existing these days be better extended and improved rather > than another one added;  we were always joking about 3 firewalls but if > we keep going this path we can soon start joking about 9 tracing > mechanisms and that will be a major mess for sysadmins.  I can see from > when this work was coming and back then it might have made sense this > way; but more than a decade has passed.. > Thanks for your input. In general, I agree with you; it is preferable to extend existing mechanisms than add something new with duplicated functionality, and I tend to look for this option first. Conversely, I feel that a one-size-fits all tracing framework is not possible, as what data is captured and how it is presented is highly dependent on the meaning/nature of that data. Put differently, we will always require more than one tracing mechanism for different types of tracing tasks. In reviewing the existing tracing options, I did not find that building this functionality on top of them to be any easier or more desirable. TSLOG covers much of the same area but with a different notion of tracing (i.e. recursive event tracing based around function entry/exit as opposed to one-shot events). The intended consumer of its data is a set of python scripts, so it is presented much differently than the human-readable log of events that boottrace produces. KTR has a KTR_INIT class that appears completely unused and comes close to realizing the same purpose, but would still require the addition of a whole new interface for creating new ktr events from userspace. Rather than bend these existing tools to meet these needs it seems better to me to leave them to do what they are good at, and instead add something new that is purpose-built and equally limited in scope (for which the work is already complete). > /bz On another note, it was misleading of me to call boottrace a 'framework', as this implies a much wider scope than what it achieves. More accurate would be to call it a facility. I intend to move forward and commit this work later this week if there are no lingering comments. Cheers, Mitchell