From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 21-APR-1993 00:24:16.53 To: MACRO32@WKUVX1.BITNET CC: Subj: Re: $FAO - safe to use above IPL 2? In article <1993Apr19.183851.1856@cmkrnl.com>, jeh@cmkrnl.com writes: > In article <01GX6X5WLLHE8WW38R@MONMOUTH-etdl1.Army.MIL>, > "Brian J. Schenkenberger, VAXman" writes: >> Jamie. I did look it up, in SDA. >> >> Looks like all the code is in pageable memory. EXE$FAO is in >> MESSAGE_ROUTINES, the MESSAGE_ROUTINES' LDRIMG$L_PAGE_R_BASE has >> an address defined, LDRIMG$L_PAGE_W_BASE is zero. :-( >> >>>(I suppose I could always check S0_PAGING before calling $FAO....) >> Yep! > > Hmmm. I suppose I could always send a special kernel AST to a process > (*any* process) to do the $FAO at IPL 2, then report back! > > Nyyahh... > > --- jeh Brian sent me e-mail to ask how in the world I was going to get an AST delivered anywhere while I'm at fork level. Er, well, ah, you see, I'd have the AST report back with the formatted buffer LATER! Yeah, that's it! Of course the SKAST could simply send the formatted string to the mailbox. What I ended up doing is better: The driver simply sends the "binary" parameter values and the $FAO control string through the mailbox. The process-level code constructs a descriptor for the control string and points $FAOL's fourth argument at the list of parameter values. Simple. I'll post the code in a few hours. (Since the process side is running in C, someone is sure to ask why I didn't use sprintf(). Two reasons. One, $FAOL is far faster; and two, sprintf has no easy way to let me point at an existing parameter list, I'd have to cobble up the argument list by hand.) --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA drivers, internals, networks, applications, and training for VMS and Windows NT uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG Internet: jeh@cmkrnl.com Uucp: uunet!cmkrnl!jeh CIS: 74140,2055