Date: Fri, 10 Aug 2018 12:12:42 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: Kyle Evans <kevans@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337518 - in head/sys: kern sys Message-ID: <20180810115339.X1652@besplex.bde.org> In-Reply-To: <20180810105239.J1482@besplex.bde.org> References: <201808090132.w791WAQm057199@repo.freebsd.org> <20180810081913.P1108@besplex.bde.org> <CACNAnaF%2BEHEfv2%2BaqAkx-JDxaKWmS7uLefHLqjO7Te8h_30Mew@mail.gmail.com> <20180810105239.J1482@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180810115339.X1652>