Re: OSI Replacement for rebootHookAdd ???

[Andrew Johnson <anj@aps.anl.gov>]

Eric Bjorklund wrote:
> Personally, no, I am neither reluctant or unable. But I am working on 
> drivers that will be distributed to lots of other sites (which is why I 
> am in to portability these days) and I can't vouch for their situations. 
> Plus there is just the general inelegance of requiring a special BSP 
> patch in order for our "portable" routines to run.
>
> So I guess the question remains -- would it be reasonable to register 
> the exit handler with rebootAddHooks in the event that sysAtReboot is 
> not found?

The problem with the fallback solution that you propose is that it will 
only work with some drivers, and not with any that make use of the 
vxWorks network stack because the network gets shutdown before any 
regular rebootHook routines are called.

A site that really can't modify their BSP can put the following 
(untested) line in their st.cmd file instead:
  rebootHookAdd(epicsExitCallAtExits)

I think our position should be that any site that wants the proper 
cleanup behaviour should install the BSP patch.  Adding the qualifier 
"but if you don't have any network devices you don't need to" will just 
cause the site to have to solve the problem at a later date when they 
*do* add a network device.  IMHO the right place to fix the problem is 
to force it to come up early, rather than adding code to work around it 
that doesn't completely solve it.

We have other facilities in EPICS that don't work on an unpatched 
vxWorks BSP:
* the 'veclist' command won't show anything useful on most unmodified 
PowerPC BSPs because it uses intVecGet() which is not implemented by the 
WRS BSPs (in this case though it's not that useful even on a modified 
BSP since it can only show the first ISR in the chain for each interrupt 
vector; I would like to remove veclist completely from EPICS, its 
functionality really belongs in the BSP).
* The devLibA24Malloc subsystem relies on BSP provided routines on CPUs 
which don't export the whole of RAM to the A24 space (which covers every 
current VME CPU board from Motorola); this subsystem probably isn't used 
much any more, but it is a documented part of devLib that is needed for 
some hardware to work.

However I realize that my position may seem a bit hard-line, and if the 
concensus reached by discussion here is to install Eric B's workaround I 
will do so.

Discuss...  (but enjoy the Labor Day weekend first if you're in the US!)

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger