From owner-svn-src-all@freebsd.org Fri Aug 10 02:12:53 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B350F1055583; Fri, 10 Aug 2018 02:12:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 30E06728E9; Fri, 10 Aug 2018 02:12:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id B0AA8D733C6; Fri, 10 Aug 2018 12:12:43 +1000 (AEST) Date: Fri, 10 Aug 2018 12:12:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Kyle Evans , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337518 - in head/sys: kern sys In-Reply-To: <20180810105239.J1482@besplex.bde.org> Message-ID: <20180810115339.X1652@besplex.bde.org> References: <201808090132.w791WAQm057199@repo.freebsd.org> <20180810081913.P1108@besplex.bde.org> <20180810105239.J1482@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=x7bEGLp0ZPQA:10 a=8fF8oHDZ2iCZZMA05wEA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 02:12:53 -0000 On Fri, 10 Aug 2018, Bruce Evans wrote: > On Thu, 9 Aug 2018, Kyle Evans wrote: > ... >> When you say you call msgbufinit() earlier-- before the static >> environment is even setup, or at least after that? > > The above is with a simplified version that first calls msgbufinit() > after the static env is set up. In other working versions, msgbufinit() > is called long before the static env is set up. In a commented out > version, a small MI msgbuf is statically initalized so that some msgbuf > is always mapped, but msgbufmapped still starts as 0 and msgbufinit() > must still be called to synchronize. Some synchronization is needed > since the msgbuf uses broken mutex locking and mutexes use curthread and > curthread is not initialized early. The simplified versions delay the > msgbufinit() calls until mutexes are initialized enough, and this > accidentally moves them after other initializations. > > So the tunable is unavailable in the best version :-(. The small initial > msgbuf could even start with the statically initialized buffer containing > the tag, and must if it is to be ready to go without a synchronization call. The tag can be added later fairly easily, and this order corresponds to the problem being solved (that we don't know where the data for the new boot starts iff there is old data): - start with a small statically initialized msgbuf. No need for a tag; the new data starts at the start of the buffer - write new data to this buffer - reinit is not really initialization, but supplies data from the previous boot. Construct the new buffer as the concatenation of the old data, a tag to delimit the new data, then the new data. But I think a variable tag is worse than a fixed tag. With a fixed tag, it is easy for dmesg, syslogd and users to search for the tag and replace it by a better one determined using full runtime resources. E.g., use sed on /var/log/messages to find the last instance of the tag and replace it by something depending on the current context, while a tunable tag must be set earlier and then all utilities and methods for finding and modifying must understand its variations. Bruce