svn commit: r337518 - in head/sys: kern sys

[Kyle Evans]

On Thu, Aug 9, 2018 at 9:12 PM, Bruce Evans <brde at 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