From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 20-OCT-1993 08:20:57.49 To: EVERHART CC: Subj: Re: AXP special kernel ASTs X-Newsgroups: comp.os.vms From: dipirro@star.enet.dec.com (Steve DiPirro) Subject: Re: AXP special kernel ASTs Message-ID: <1993Oct19.175312.4706@nntpd.lkg.dec.com> Sender: usenet@nntpd.lkg.dec.com (USENET News System) Organization: Digital Equipment Corporation Date: Tue, 19 Oct 1993 17:52:30 GMT Lines: 31 To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article <931018163520.60@arisia.gce.com>, EVERHART@arisia.gce.com writes... >It is still perfectly feasible to send special kernel ASTs on AXP; >they work much the same as on VAX. What is NOT feasible without >significant macro-64 hooks is grabbing a chunk of pool, copying code >into it, and firing off ASTs into it and getting the code to do the >same to get back... While everything he said is true, I thought I'd point out a couple of other differences. First, on AXP in the release following V1.5, special kernel mode AST routines can be standard calls as well as the older-style JSB interfaces. So you can use a C routine without any special routine linkage as a special kernel mode AST. Also, in *most* instances, people used the technique described above (allocating pool, copying code into it, firing it off as an AST to another process) to read and/or write memory (P0/P1 space) in the context of another process. If that's all you need to do (and you obviously have the privileges, etc. to run in kernel mode to start with), there are new exec routines which do precisely that. They do the work for you in order to read and write memory in the context of another process. In fact, they'll do registers (GPRs) too. The routines are called EXE$READ_PROCESS and EXE$WRITE_PROCESS and must be called from kernel mode at IPL 0 to work. Linking /SYSEXE will resolve them. The interfaces can be found in the PROC_READ_WRITE module in SYS for those of you with listing/source kits. ------------ Steve DiPirro dipirro@star.enet.dec.com ------------