How do sys$get type kernel mode services really work?

[Roger Tucker]

My question is how do sys$get... type system services work on VMS? Ok. Maybe this isn't the right forum to be asking questions about operating system internels, but I'm currious. For example, SYS$GETJPI() makes the jump to kernel mode, probes the arguments in the callers mode, and if everything looks good, has to raise IPL to SCHED to get the information. The way I understand this is that GETJPI can't write the information to the user-mode item list because it might fault, and above ASTDEL this would be bad. So, it must just gather the information needed to the kernel stack, drop back to ASTDEL, to probe and write the information to user-mode address space. Is this correct? So all sys$get() type system services, that go above ASTDEL must just gather the information (most likely on the kernel stack) and then drop back to ASTDEL to parse the item list, even after probeing, we cannot write to the item_list above ASTDEL because we might fault user space. Am I missing something or is this correct?

Another question but the above is more important. How does LINUX work in this case? I couldn't find a probe in the Linux source code, but I did find a routine that writes from kernel to user-space that does a sort of write trapping the error. That might even be better than trying to probe everything before hand... Any comments?

[John Gillings · Accepted solution]

Roger,

>So, it must just gather the information
>needed to the kernel stack, drop back to
>ASTDEL, to probe and write the information
>to user-mode address space. Is this
>correct?

Kind of. You're correct that any memory accessed at high IPL needs to be locked into memory, but that's not the main reason for not writing directly to the argument list at high IPL. After all, we could simply lock those pages in memory before raising IPL.

The biggest issue with the $GETxxx[W] services is the asynchronous gathering of information. For example, many things that $GETJPI returns can only be found in the context of the target process.

This is achieved by sending a special kernel AST to the target. The requesting process can then return to the caller caller (back to user mode, IPL 0). They're free to continue processing other stuff or wait around for the service to complete with $SYNCH. When the requested information has been found, a spKAST is sent back to the requestor. Back in requestor process context, we write the information to the item list asynchronously (note this may be done in kernel mode, but since there aren't any system data structures to be synchronised against, it's most likely at IPL 0, so page faults are not an issue), set the event flag, write to the IOSB and queue a user mode AST if one was requested.

Same is true for the other asynchronous services. In many cases even data that may be available directly is still written using the spKAST mechanism because it's easier to code everything for the general case (that said, there are also some specially optimized code paths to expedite common requests).

How does this work in Linux? Sorry, no idea. This is the OpenVMS forum. Maybe ask in a Linux forum?

(I don't think Linux has ASTs.)

[Ian Miller.]

parhaps linux just writes to the user buffer hoping it works and traps the error if something bad happens? I don't know.

You need to save up and buy a copy of the Internals and Data Structures Manual. Its out of date but a lot of it is still true.. It has these interesting quotes at the start of each chapter and I like the picture on the front too :-)