Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp7472719ybh; Thu, 8 Aug 2019 16:47:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8ABbqu9hZVWYw+dP3TWCI55bNqMmfuQGSgf5Myt7dKD299oiMh9n0Vaqoza9f+NnMhfeW X-Received: by 2002:a17:90a:8c18:: with SMTP id a24mr6372124pjo.111.1565308035308; Thu, 08 Aug 2019 16:47:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565308035; cv=none; d=google.com; s=arc-20160816; b=K1E5PBNdOkDp6eQuol7VuUradmqYnRHExlxqqlYbIy0JC9/88nAq1LFzP5CDW/iiu+ y/8+id3IxKkR9N/+TTBbOxrfsOJbV9raIpEkbmHLtGyVuAR89d+cu1XdGX6xwKyUBQNc e06AhSmx2xlTQD+bV+pFzS3BKtkiDgHBYDcBkP+QNbErvULqSpc4dg/xwuClQVlKEsDf Lx974MKUF2XB6Od9zNhKg3twkA5aBVxsU5G4+4sUVHyxfsXDGvwQ/G1a/+wUy4PRfN9l 9mghEpdH2Nd1bzP1G89xcbDSwkQG/1TczXdxB1lmcImCLgovM24HRkV0hMMUbPQ0jf0w /srw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=O+3FA4NYe2jbU38DPYQ0d6FbmQlam2ltx2A7G0Q7x28=; b=kEpL3awOrWU/WtruCtp05yUfkMhvHEsjqlg/fe5cEGvXw8MJA6KsBixnmi/6A6wJMF be9Ysw8UoEi9QU/m5VQBKiC917cgD/VkQJq8TMsFvs1bmg8RjIIwhRotNtDaVNsIqYSd qv/sLpN9AMQ8v5SxuSgw5xgGCapDySQQTRt6egCPIK960ZFMuD84od5t0HCGfNBjUayu InAwfKxGaN0NieJMh2KLCpQp0VzLtAgZmzHXADzNoE2L0u8vt4l763fM+FbAKpxo/wwc YkOmx0tyiWXaS6EjHfMqktxCsaPTaqSbD32lFYNyZfJZ62NuKrm+k3KeqE6a3sZCkkMz 1odQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r14si39749595pli.257.2019.08.08.16.46.59; Thu, 08 Aug 2019 16:47:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404690AbfHHXp1 (ORCPT + 99 others); Thu, 8 Aug 2019 19:45:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:53348 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732375AbfHHXp1 (ORCPT ); Thu, 8 Aug 2019 19:45:27 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 771872173E; Thu, 8 Aug 2019 23:45:25 +0000 (UTC) Date: Thu, 8 Aug 2019 19:45:23 -0400 From: Steven Rostedt To: Linus Torvalds Cc: John Ogness , Linux List Kernel Mailing , Peter Zijlstra , Petr Mladek , Sergey Senozhatsky , Greg Kroah-Hartman , Andrea Parri , Thomas Gleixner , Sergey Senozhatsky , Brendan Higgins Subject: Re: [RFC PATCH v4 9/9] printk: use a new ringbuffer implementation Message-ID: <20190808194523.6f83e087@gandalf.local.home> In-Reply-To: References: <20190807222634.1723-1-john.ogness@linutronix.de> <20190807222634.1723-10-john.ogness@linutronix.de> <874l2rclmw.fsf@linutronix.de> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 Aug 2019 16:33:20 -0700 Linus Torvalds wrote: > To which the obvious solution is "just use a different buffer for the > next boot". But that brings up the *second* big issue with a > reboot-safe buffer: it can't just be anywhere. Not only do you have to > have some way to find the old one, the actual location may end up > being basically fixed by hardware or firmware. Could we possibly have a magic value in some location that if it is set, we know right away that the buffer here has data from the last reboot, and we read it out into a safe location before we start using it again? -- Steve