[Info-vax] Database Journaling, Failover

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri Feb 14 09:42:20 EST 2014


On 2014-02-14 02:53:01 +0000, johnson.eric at gmail.com said:

> On Thursday, February 13, 2014 8:24:07 PM UTC-5, Stephen Hoffman wrote:
> 
>> Intercepting a $qio system service is easy, either to a specific device 
>> or just grabbing everything.
> 
> What technique(s) did you have in mind?

There are various options available.  Depending on the context — the 
system architecture and the applications requirements and performance 
requirements and the source code availability and the particular system 
service or RTL call that you're interested in — and yes, some of the 
following are version- or architecture-specific.

Options: rework the app source code (obvious), patch the app binary, 
patch system service transfer vector, trap the call at run-time (I've 
some stuff around with the debugger embedded into the application), 
intercept the system service call at run-time (likely via SSI), patch 
the kernel (whee!), or use a device driver (or a driver and an ACP, if 
you need some outer-mode code and don't want to "borrow" some random 
process for that) as a shim.

For an RTL call or a UWSS — of which $qio is obviously not — shim or 
patch the image that gets activated.  For a production app with source 
code available, re-coding the $qio can be the most maintainable 
approach, though using a driver shim and the altstart interface into 
the "real" device can work nicely.

Maintaining an operating system by patch is absurdly expensive.  
Maintaining a specific app that way can be feasible, at least for a 
while.



-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list