Hi everyone.
The "add_drv -n" command updates the configuration files used by the
kernel to keep track of drivers and the devices they map to. The "-n"
part tells the command to stop short of actually loading the driver into
the kernel and attaching it. A reboot is the generally-accepted way of
getting the driver operational after "-n". (There may also be other ways
I don't know about.)
"add_drv -n" is currently done by IPS driver actions. There are also
several SVR4 package post-install scripts which do it too. However, a
reboot step is out of the question when Driver Update is done, as Driver
Update is intended to install drivers into temporary ramdisk images
which get completely re-created upon each reboot.
I just met with engineers responsible for loading kernel drivers, with
an engineer who interfaces with large customers, and with an engineer on
the IPS team. Here's what I learned:
1) A true driver update (that is, replacement of an installed,
operational driver with another driver without a reboot) of a non-buggy
driver should be within scope of the Driver Update project. It is
considered a driver bug by the driver management engineers if a driver
is not unloadable (e.g. its _fini() routine returns EBUSY). If the old
driver can be unloaded, the new one can replace it and become active
without a reboot.
I plan on updating the functional spec to change the scope to a true
driver update. If it doesn't work, Driver Update can say so and
continue on to the next driver; but it should try.
2) The "-n" option to add_drv shouldn't be necessary. It was originally
there to prevent the system from panicking due to loading of a buggy
driver. But if the driver isn't buggy, no need.
While the IPS team will take a protective, cautious approach, driver
actions will be changed to produce an end result functionally equivalent
to calling "add_drv" without the "-n".
3) What about all those legacy post-install scripts in SVR4 driver
packages, which could have "add_drv -n" in them? Since "-n" isn't
supposed to be needed, existence of "-n" in those scripts could be
considered a bug. It would be nice for Driver Update to work around
them, so that such packages would "just work" with Driver Update. For
now, I suggest this to be an RFE.
No change to the spec is needed for this. However, it should be clearly
documented that postinstall scripts which use "add_drv -n" are not going
to be compatible with Driver Update (at least until the RFE is in
place). Note though, that they already aren't compatible with the
existing ITU either though...
4) There are two types of ITU images: both need to be handled. (I
thought there was only one.) I'll need to look into this for more info.
No spec change is needed for this either. Checks for ITU image type and
proper processing will have to be handled under the hood.
I thought these were some large changes, hence this email. If you have
comments/suggestions/concerns, please reply by COB Friday 8/21.
Thanks,
Jack
