Ignite-UX Custom Configuration files

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