From owner-freebsd-hackers Mon Jul 27 14:34:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14564 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 14:34:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14457 for ; Mon, 27 Jul 1998 14:34:10 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id RAA09798; Mon, 27 Jul 1998 17:33:31 -0400 (EDT) Date: Mon, 27 Jul 1998 17:33:30 -0400 (EDT) From: Snob Art Genre Reply-To: ben@rosengart.com To: David Wolfskill cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM In-Reply-To: <199807271745.KAA25470@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Jul 1998, David Wolfskill wrote: > However, as a follow-on to a discussion I was having with someone else > (where I was doing a bunch of whining about the challenges I was having > in "automatically" being able to determine the configuration of a given > FreeBSD box), the random idea came up that *IF* the kernel could stash > away the results of its probing in some way that might be amenable to > access by suitably-privileged processes at times arbitrarily distant > from re-boot (i.e, scannning logs & output of dmesg won't do the job), > this *might* be sufficiently useful to warrant some effort. /var/run/dmesg.boot Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message