HP-UX 11.23 Kernel Configuration Tools -- Feedback?

[Steven Roth]

Now that HP-UX 11.23 (aka 11iv2) has been out for a year, the team responsible for the new kernel configuration tools would like feedback on them. These are the kc* commands: kconfig, kctune, kcmodule, etc. We still have time to make changes to them for the subsequent release, so any suggestions for improvements are welcome.

What have you liked about the new tools? What have you disliked? What has been confusing?

Thanks in advance for your feedback...

[Geoff Wild]

I know this is late - but I am trying to get kctune to display like the old kmtune (for comparison reasons)...

Rgds...Geoff

[Steven Roth]

Geoff, I'm sorry, but there is no way to get kctune to produce the same output format as the old kmtune.

[Geoff Wild]

Okay - I got a work around - what I needed was a "nicely" formatted view of Dynamic Kernel Parameters - just realized the kctune outputs it under the "Changes" column as "Immed" or "Imm (auto disabled)".

I have to hurry - giving a presentation on 11iv2 in an hour!

Thanks...Geoff

[Biswajit Tripathy]

Steven,
Execuse me if I have mentioned this to you
before :-)

When I explicitely execute kcmodule to load a
DLKM module, the module is loaded as expected;
but my complain is, it is automatically loaded
even after the reboot. Since I did not use '-h'
option, I would have expected the module to stay
unloaded in the next boot. I might be wrong, but
as far as I remember, the hp-ux 11.11 tools
(kmadmin / kmsystem etc) behaved that way.

Is there any specific reason why it was designed to
behave this way?

- Biswajit

[RAC_1]

I am with with kc* commands. However, as Biswajit pointed out, I would also like to know, was it designed that way??

Anil

[Steven Roth]

Biswajit and RAC,

As you noticed, the KC tools are designed to make all changes persist across reboots. Any time you change a tunable, load a module, etc., that change remains in force across reboots.

This behavior addresses a frequent customer complaint with the old tools. It's also implied by the fact that HP-UX is intended to run without reboots for months at a time. By the time a reboot occurs, the fact that a change was made could be months in the past and long forgotten, and applications can "break" because of the "loss" of the change.

Changes that are intended to last only until reboot are rare (and arguably inappropriate) in a production environment. In a development environment, however, they are occasionally desirable. If you have a need, for example, to load a module but leave it unloaded at next boot, you can accomplish this with
kcmodule modulename=loaded
followed by
kcmodule -h modulename=unused

Steve

[Biswajit Tripathy]

Steven wrote:
> Changes that are intended to last only until
> reboot are rare (and arguably inappropriate)
> in a production environment.

Well.. what I had in mind is something like the
following. What if a product wants to run a series
of commands to configure the product before it
loads it's DLKM module and all this is done in a RC
script. In that case, when the product is installed
for the first time and system reboots, the load of
DLKM module would happen when RC script
executes the configuration commands followed by
executation of kcmodule(1M) to load the DLKM
module. In subsequent reboots, the DLKM module
is loaded right at the beginning (before any of the
RC1 scripts are executed) and hence before the
series of configuration commands that are in the
product RC script. This could potentially create a
problem.

Ofcourse, this scenerio is purely speculative and
I don't know of any product that faces this
problem. So you might be correct in saying that
this is rare in a production environment.

- Biswajit

[Steven Roth]

Biswajit wrote, "What if a product wants to run a series of commands to configure the product before it loads it's DLKM module and all this is done in a RC script."

That should not be done in an rc script. It should be done in the module's preparation script, for just the reason you describe. If the module is marked with a load time of "run", and the commands are in the "preload" part of the module's preparation script, then they will be run before the module is loaded as you desire.

Steve