[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