Re: loader.conf ignores setting variable ending in _type

On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote:
> On Tuesday 21 July 2009 02:52 pm, Andrew Gallatin wrote:
> > Hi,
> >
> > I maintain the mxge (10GbE) driver.  A user complained to me
> > that one of my driver's tunables was ignored when he set it
> > in /boot/loader.conf.   I reproduced his problem both on -current
> > and 7.2.  I think there may be some quirk which is causing the
> > loader to ignore this variable, but my 4th skills are
> > non-existent, and I'm looking for some help.
> >
> > To reproduce this bug, I used a loader.conf which
> > looks like this:
> >
> > console=comconsole
> > if_mxge_load="YES"
> > mxge_eth_z8e_load="YES"
> > mxge_rss_eth_z8e_load="YES"
> > hw.mxge.rss_hash_type="2"
> > hw.mxge.max_slices="2"
> >
> >
> >
> > After interrupting the boot, I could confirm that rss_hash_type
> > was not set:
> >
> > .................................................................
> >. Hit [Enter] to boot immediately, or any other key for command
> > prompt. Booting [/boot/kernel/kernel] in 8 seconds...
> >
> > Type '?' for a list of commands, 'help' for more detailed help.
> > OK show hw.mxge.max_slices
> > 2
> > OK show hw.mxge.rss_hash_type
> > variable 'hw.mxge.rss_hash_type' not found
> > .................................................................
> >..
> >
> > I have no problem setting hw.mxge.rss_hash_type while the machine
> > is up via kenv.  Also, it seems to stick when set manually from
> > the loader.
> >
> >
> > After poking around for quite a while, I noticed that the loader
> > refuses to honor any variable ending in _type loaded from
> > loader.conf.
> >
> > Is this because the suffix "_type" (for module_type) is somehow
> > reserved and I should not be using a tunable ending in _type
> > Or is this a bug in the loader?
>
> Yes, it is reserved.
>
> loader.conf(5):
>
>      *_type	Defines the module's type.  If none is given, it
> defaults to a kld module.

Actually, I wanted to quote this:

loader.conf(5):

    WARNING:	developers should never use these suffixes for any
		kernel environment variables (tunables) or conflicts
		will result.

Jung-uk Kim