Re: getenv_string broken?

From: Nate Lawson <nate_at_root.org>
Date: Tue, 3 Feb 2004 12:31:29 -0800 (PST)
On Thu, 29 Jan 2004, Ruslan Ermilov wrote:
> On Wed, Jan 28, 2004 at 10:47:00AM -0800, Nate Lawson wrote:
> > On Wed, 28 Jan 2004, John Baldwin wrote:
> > > On Wednesday 28 January 2004 01:28 am, Nate Lawson wrote:
> > > > On Tue, 27 Jan 2004, John Baldwin wrote:
> > > > > On Tuesday 27 January 2004 12:42 am, Nate Lawson wrote:
> > > > > > I have a getenv_string() that is never being evaluated.  I declared it
> > > > > > as follows:
> > > > > >
> > > > > > static char acpi_os_name[128];
> > > > > > TUNABLE_STR("hw.acpi.os_name", acpi_os_name, sizeof(acpi_os_name));
> > > > > >
> > > > > > The contents of acpi_os_name are never filled in from the variable I
> > > > > > declared in /boot/loader.conf. Just to be sure, I made a loop that
> > > > > > prints out the contents of kenvp.  It does not have hw.acpi.os_name.
> > > > > >
> > > > > > Here is a snippet of the kenvp array, right where my tunable should be
> > > > > > (os2 is from a test below):
> > > > > >
> > > > > > name: hint.vt.0.disabled=1
> > > > > > name: hw.acpi.os2=8
> > > > > > name: hw.acpi.reset_video=0
> > > > > > name: hw.acpi.verbose=1
> > > > > > name: hw.cbb.start_memory=0xc0203000
> > >
> > > How did you dump this?  If os_name isn't in the list, then that is going to be
> > > a problem of course. :)  That would indicate that a bug in the loader though
> > > and not in getenv_string().
> >
> > I added a loop that prints out the entire kenv each time getenv_string is
> > called.  This is possibly a loader bug although I'm very curious how
> > surrounding variables make it into the list but not hw.acpi.os_name.  It's
> > possible they're all ints while mine is a string.  The only other string
> > is module_path, so perhaps I should try overloading that in loader.conf
> > and see if it also fails.
>
> What's wrong with just using kenv(1)?

Yeah, that shows the bug too.  Something in the loader is not picking up
my TUNABLE_STR declaration.  It may be related to acpi.ko being a module
since the only other string is module_path, which is defined in the
kernel.  But tunable ints in acpi work.  Anyone care to help debug this?

-Nate
Received on Tue Feb 03 2004 - 11:31:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:41 UTC