signed 32-bit arithmetic for decimal values, and it has problems when values exceed this limit. If larger values are needed, convert them to hexadecimal since the shell does not evaluate them.

Note that any allowable syntax supported by the config command can be used in mod_kernel keywords. This includes formulas. For example, it is possible to use:

mod_kernel += "ninode (20+8*MAXUSERS+NPTY+" + ${"%d" _inc} + ")"

assuming _inc has been initialized to some value in the configuration file.

The = operator will override any prior global mod_kernel assignments. The += operator will add to any prior settings. Notice that mod_kernel statements may also be associated with a sw_sel definition. The = operator does not have any effect on mod_kernel assignments made in a sw_sel.

Beginning with the 11.23 release, the format for cplx-string arguments was enhanced. There are two new formats specifically that are understood (in addition to the older formats). They are:

mod_kernel += "tunable name value" mod_kernel += "module name [state]"

The former is the same as how tunables were handled before only the keyword tunable is put at the beginning. The latter is how kernel modules are added to the system. The optional state argument has one of four values: static, auto, loaded and best. No checking is performed on this value. See kcmodule(1M) for more information.

Actions involving mod_kernel are done before those for both set_kernel and rm_kernel.

set_kernel = cplx-string set_kernel += cplx-string

This keyword is the same for drivers as the mod_kernel keyword in that it will add the driver to the kernel. For tunables it differs from mod_kernel in that it will set the tunable to the arbitrary value as defined by cplx-string. No comparisons or checks are performed with prior or default values. Actions involving set_kernel are done after those for mod_kernel but before those for rm_kernel.

rm_kernel = cplx-string rm_kernel += cplx-string

This keyword will remove the driver or tunable from the /stand/system file. For drivers, this implies the driver will be removed from the kernel. For tunables, this implies that the tunable will revert back to its default value. Actions involving rm_kernel are done after those for both mod_kernel and set_kernel.

The following example shows that a new category is created, called KernelConfig, which defines sets of kernel parameters that can be applied to a system. Ignite-UX does not do any parameter validation. That is followed by the "no-op" sw_source clause:

sw_category "KernelConfig" {

124