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>