Date: Thu, 9 Aug 2018 21:25:13 -0500 From: Kyle Evans <kevans@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: 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: <CACNAnaFkMhWVSQEm0uyKLa7V8gh9JZFd9Q7HHNox%2BZHa6pspYw@mail.gmail.com> In-Reply-To: <20180810115339.X1652@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> <20180810115339.X1652@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 9, 2018 at 9:12 PM, Bruce Evans <brde@optusnet.com.au> wrote: > 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. > I honestly have very low expectations for the tunable's use, but it's a low-cost addition and I find it more useful in a less automated context. One that I've had recently would have been implemented with the following process: 1. Boot -v into installed kernel with normal tag, ---<<BOOT>>-- 2. Briefly review `dmesg`, notice issue with clock driver 3. Install new kernel with changes to said clock driver. Tag it ---<<A20CLKNG>>--, boot -v 4. Review `dmesg` again to observe changes The non-standard tag would certainly be an anomaly, but it gives me the benefit of discerning a standard boot from this one in which I fiddled with the A20 clock driver without having to compile a non-standard boot tag into the kernel. It also gives me a clear indicator as I'm paging through output to quickly at-a-glance realize that I've reached a new (or the correct) boot. I'll likely commit the modified version soon, anyways, and we can hash out any further details after 12 branches. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaFkMhWVSQEm0uyKLa7V8gh9JZFd9Q7HHNox%2BZHa6pspYw>