Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Mar 2019 08:43:15 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Ravi Pokala <rpokala@freebsd.org>, src-committers <src-committers@freebsd.org>,  svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r345680 - head/sys/conf
Message-ID:  <CACNAnaEmNUZw6R0QThw=AgkU6Xx4XhMybhLHnjV0k4dU2rrx0w@mail.gmail.com>
In-Reply-To: <20190329164644.X957@besplex.bde.org>
References:  <201903290400.x2T40kp7013212@repo.freebsd.org> <CAF5D833-B3C3-4AD6-9B77-0363C56E93E9@panasas.com> <20190329164644.X957@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 29, 2019 at 1:40 AM Bruce Evans <brde@optusnet.com.au> wrote:
>
> On Thu, 28 Mar 2019, Ravi Pokala wrote:
>
> > -----Original Message-----
> > From: <owner-src-committers@freebsd.org> on behalf of Kyle Evans <kevans@FreeBSD.org>
> > Date: 2019-03-28, Thursday at 21:00
> > To: <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>
> > Subject: svn commit: r345680 - head/sys/conf
> >> [... snip ...]
> >>  # Maximum boot tag size the kernel's static buffer should accomodate.  Maximum
> >>  # size for both BOOT_TAG and the assocated tunable.
> >>  options     BOOT_TAG_SZ=32
>
> This bug remains unfixed.  32 is the default.  This option shouldn't exist.
> Instead, just use size strlen(BOOT_TAG) + 1 for the static string and keep
> the dynamic string in the environment.  The string is only used once, and
> msgbufinit() already has to check both the static string and the environment
> to find the right string (it does this by fetching the dynamic string to
> overwrite the static string, but it is easier to not use a tunable or
> support a sysctl and just keep the dynamic string in the environment).
>

I will consider doing just that. Where I was going with this turned
out to be logistically annoying because of kenv's val length
limitation. I had some one-off test setups where I wanted to dump some
cherry-picked information about the build into the BOOT_TAG via the
tunable for reference when looking back and comparing msgbufs between
boots. However, we can't reasonably support values the length I need
in the environment (with a caveat, see [0]), so I would need to break
them up -- likely by hand, which means I'm more inclined to just hunt
down the current BOOT_TAG and modify these msgbufs post-mortem to
include the information I want to see. This process is still less
convenient than it would've been to be able to set it in loader.conf,
because for many of these I already have to edit loader.conf for other
reasons.

Enlarging the BOOT_TAG_SZ in the 'breaking up' scenario is convenient
because I'd rather not stitch the boot tag back together from the
environment when observed via sysctl -- I want to do this once, and
observe it exactly as it is after it's printed, so pushing it into the
boot tag buffer that already holds the statically configured boot tag
is convenient there. There are other reasons it'd be convenient to
push them into the same buffer, but they're rather moot now since I'm
likely the only one that wanted to use larger boot tags like that and
I'm just not going to go that far to support my use case.

[0] Merging into the dynamic environment is kind of broken here, and I
didn't really fix it when I touched that. We only verify that the
whole assignment line isn't more than MNAMELEN + MVALLEN + 2, rather
than the individual components, so I could take advantage of this and
have way-too-long values... that's not much more helpful, though.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEmNUZw6R0QThw=AgkU6Xx4XhMybhLHnjV0k4dU2rrx0w>