HP OpenVMS Systems Documentation

Order Number: AA--QSBGD--TE

Alpha privileged-code applications link against the system base image (SYS$BASE_IMAGE.EXE) on OpenVMS Alpha. This guide explains the changes that might impact Alpha privileged-code applications as a result of the OpenVMS Alpha 64-bit virtual addressing and kernel threads support provided in OpenVMS Alpha Version 7.0 and later.

Privileged-code applications from versions prior to OpenVMS Alpha Version 7.0 might require the source-code changes described in this guide.

Revision/Update Information: This manual supersedes the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications, Version 7.1

Software Version: OpenVMS Alpha Version 7.3

Compaq Computer Corporation
Houston, Texas

© 2001 Compaq Computer Corporation

Compaq, VAX, VMS, and the Compaq logo Registered in U.S. Patent and Trademark Office.

OpenVMS is a trademark of Compaq Information Technologies Group, L.P. in the United States and other countries.

All other product names mentioned herein may be trademarks of their respective companies.

Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

ZK6466

The Compaq OpenVMS documentation set is available on CD-ROM.

Alpha privileged-code applications link against the system base image (SYS$BASE_IMAGE.EXE) on OpenVMS Alpha. This guide explains the changes that might impact Alpha privileged-code applications as a result of the OpenVMS Alpha 64-bit virtual addressing and kernel threads support provided in OpenVMS Alpha Version 7.0.

This guide is intended to help developers using privileged-code interfaces understand how the changes in OpenVMS Alpha Version 7.0 might affect their applications and device drivers.

Nonprivileged code applications should not require any source code changes and should run without modification on OpenVMS Alpha Versions 7.0 and 7.1.

The information in this document applies only to privileged-code applications on OpenVMS Alpha systems; applications on OpenVMS VAX systems are not affected.

Intended Audience

This guide is intended for system programmers who use privileged-mode interfaces in their applications.

Document Structure

The guide is divided into three parts:

• Part I describes the infrastructure changes that might affect privileged-code applications and provides guidelines for upgrading them to OpenVMS Alpha Version 7.0.
• Part II describes the changes that can be made to customer-written system services and device drivers to support 64-bit addresses and kernel threads.
• The appendixes contain descriptions of I/O routines, I/O data structures, kernel threads routines, and kernel threads macros.

For more information about how to use this guide, see Chapter 1.

Related Documents

• OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features¹
• OpenVMS Programming Concepts Manual
• OpenVMS Record Management Services Reference Manual
• OpenVMS System Services Reference Manual: A--GETUAI and OpenVMS System Services Reference Manual: GETUTC--Z

For additional information about Compaq OpenVMS products and services, access the following World Wide Web address:

http://www.openvms.compaq.com/

Reader's Comments

Compaq welcomes your comments on this manual. Please send comments to either of the following addresses:

How to Order Additional Documentation

Use the following World Wide Web address to order additional documentation:

http://www.openvms.compaq.com/

If you need help deciding which documentation best meets your needs, call 800-282-6672.

Conventions

The following conventions are used in this manual:

OpenVMS Alpha Version 7.0 includes significant changes to OpenVMS Alpha privileged interfaces and data structures, mostly as a result of support for 64-bit virtual addresses and kernel threads.

For 64-bit virtual addresses, these changes are part of the infrastructure work needed to enable processes to grow their virtual address space beyond the existing 1 GB limit of P0 space and the 1 GB limit of P1 space to include P2 space, making a total of 8TB. Likewise, S2 is the extension of system space.

Kernel threads support causes significant changes to the process structure within OpenVMS (most notably to the process control block (PCB)). Although kernel threads support does not explicitly change any application programming interfaces (APIs) within OpenVMS, it does change the use of the PCB in such a way that some existing privileged code may be impacted.

As a result of these changes, some privileged-code applications might need to make source-code changes to run on OpenVMS Alpha Version 7.0 and later.

This chapter briefly describes OpenVMS Alpha Version 7.0 64-bit virtual address and kernel threads support and suggests how you should use this guide to ensure that your privileged-code application runs successfully on OpenVMS Alpha Version 7.0 and later.

1.1 Quick Description of OpenVMS Alpha 64-Bit Virtual Addressing

OpenVMS Alpha Version 7.0 provides support for 64-bit virtual addresses, which makes more of the 64-bit virtual address space defined by the Alpha architecture available to the OpenVMS Alpha operating system and to application programs. The 64-bit address features allow processes to map and access data beyond the previous limits of 32-bit virtual addresses. Both process-private and system virtual address space now extend to 8 TB.

In addition to the dramatic increase in virtual address space, OpenVMS Alpha 7.0 significantly increases the amount of physical memory that can be used by individual processes.

Many tools and languages supported by OpenVMS Alpha (including the Debugger, run-time library routines, and DEC C) are enhanced to support 64-bit virtual addressing. Input and output operations can be performed directly to and from the 64-bit addressable space by means of RMS services, the $QIO system service, and most of the device drivers supplied with OpenVMS Alpha systems.

Underlying this are new system services that allow an application to allocate and manage the 64-bit virtual address space that is available for process-private use.

For more information about OpenVMS Alpha 64-bit virtual address features, see the OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features¹.

1.2 Quick Description of OpenVMS Alpha Kernel Threads

OpenVMS Alpha Version 7.0 provides kernel threads features, which extend process scheduling capabilities to allow threads of a process to run concurrently on multiple CPUs in a multiprocessor system. The only interface to kernel threads is through the DECthreads package. Existing threaded code that uses either the CMA API or the POSIX threads API should run without change and gain the advantages provided by the kernel threads project.

Kernel threads allows a multithreaded process to execute code flows independently on more than one CPU at a time. This allows a threaded application to make better use of multiple CPUs in an SMP system. DECthreads uses these independent execution contexts as virtual CPUs and schedules application threads on them. OpenVMS then schedules the execution contexts (kernel threads) onto physical CPUs. By providing a callback mechanism from the OpenVMS scheduler to the DECthreads thread scheduler, scheduling latencies inherent in user-mode-only thread managers is greatly reduced. OpenVMS informs DECthreads when a thread has blocked in the kernel. Using this information, DECthreads can then opt to schedule some other ready thread.

For more information about kernel threads, refer to the Bookreader version of the OpenVMS Programming Concepts Manual and Chapter 6 in this guide.

1.3 How to Use This Guide

Read Part I to learn about the changes that might be required for privileged-code applications to run on OpenVMS Alpha Version 7.0.

Refer to Part II for information about enhancing customer-written system services and device drivers with OpenVMS Version 7.0 features.

Refer to the Appendixes for more information about some of the data structures and routines mentioned throughout this guide.

The new features provided in OpenVMS Alpha Version 7.0 have required corresponding changes in internal system interfaces and data structures. These internal changes might require changes in some privileged software.

This chapter contains recommendations for upgrading privileged-code applications to ensure that they run on OpenVMS Alpha Version 7.0. Once your application is running on OpenVMS Alpha Version 7.0, you can enhance it as described in Part II.

2.1 Recommendations for Upgrading Privileged-Code Applications

To ensure that a privileged-code application runs on OpenVMS Alpha Version 7.0, do the following:

1. Recompile and relink your application to identify almost all of the places where source changes will be necessary. Some changes can be identified by inspection.
2. If you encounter compile-time or link-time warnings or errors, you must make the source-code changes required to resolve them.
   See Section 2.1.1 for descriptions of the infrastructure changes that can affect your applications and more information about how to handle them.
3. Refer to Chapter 3 for information about the data structure fields, routines, macros, and system data cells obviated by OpenVMS Alpha Version 7.0 that might affect privileged-code applications.
4. Once your application recompiles and relinks without errors, you can enhance it to take advantage of the OpenVMS Alpha Version 7.0 features described in Part 2.

This section summarizes OpenVMS Alpha Version 7.0 changes to the kernel that may require source changes in customer-written drivers and inner-mode software. The recommendations in bold face type indicate how each change can be handled.

• Page tables have moved from the balance set slots to page table space. (Compile and link the application.)
• The global page table has moved from S0/S1 space to S2 space. (Compile and link the application.)
• The PFN database has moved from S0/S1 space to S2 space. (Compile C applications. Inspect MACRO applications for changes that might not cause warning messages. Link all applications.)
• PFN database entry format has changed. (Compile and link the application.)
• Routines MMG$IOLOCK and MMG$UNLOCK are obsolete and are replaced by MMG_STD$IOLOCK_BUF and DIOBM. (Compile and link the application.)
• A buffer locked for direct I/O is now described by SVAPTE, BOFF, BCNT, and a DIOBM.
  Be aware of code that clears IRP$L_SVAPTE to keep a buffer locked even after the IRP is reused or deleted. (Inspect the code for changes.)
• A single IRPE can only be used to lock down a single region of pages. (Compile and link the application.)
• Some assumptions about I/O structure field adjacencies may no longer be true; for example, IRP$L_QIO_P1 and IRP$L_QIO_P2 are now more than 4 bytes apart. (Compile, link, inspect the code.)
• The IRP$L_AST, IRP$L_ASTPRM, and IRP$L_IOSB cells have been removed. (Compile and link the application.)
• Two types of ACBs; an IRP is always in ACB64 format. (Compile, link, inspect the code.)
• MMG$SVAPTECHK can longer be used for P0/P1 addresses. In addition, P2/S2 are not allowed; only S0/S1 are supported. (Inspect the code.)
• Two types of buffer objects; buffer objects can be mapped into S2 space. (Inspect the code.)

The remaining sections in this chapter contain more details about these changes.

A few necessary source changes might not always be immediately identified by compile-time or link-time warnings. Some of these are:

• Pointers to a PFN database entry are now 64-bits wide. If you save or restore them, you must preserve the full 64 bits of these pointers.
• The MMG[_STD]$SVAPTECHK routine can handle only S0/S1 addresses. If you pass it an address in any other space, such as P0, it will declare a bugcheck.
• The various SCH$ routines that put a process (now kernel thread) into a wait state now require the KTB instead of the PCB. (This is not a 64-bit change, but it could affect drivers OpenVMS Alpha Version 7.0 device drivers.)

This section describes OpenVMS Alpha Version 7.0 changes to the I/O subsystem that might require source changes to device drivers.

2.2.1 Impact of IRPE Data Structure Changes

As described in Section A.9, the I/O Request Packet Extension (IRPE) structure now manages a single additional locked-down buffer instead of two. The general approach to deal with this change is to use a chain of additional IRPE structures.

Current users of the IRPE may be depending on the fact that a buffer locked for direct I/O could be fully described by the irp$l_svapte , irp$l_boff , and irp$l_bcnt values. For example, it is not uncommon for an IRPE to be used in this fashion:

1. The second buffer that will be eventually associated with the IRPE is locked first by calling EXE_STD$READLOCK with the IRP.
2. The irp$l_svapte , irp$l_boff , and irp$l_bcnt values are copied from the IRP into the IRPE. The irp$l_svapte cell is then cleared. The locked region is now completely described by the IRPE.
3. The first buffer is locked by calling EXE_STD$READLOCK with the IRP again.
4. A driver-specific error callback routine is required for the EXE_STD$READLOCK calls. This error routine calls MMG_STD$UNLOCK to unlock any region associated with the IRP and deallocates the IRPE.

This approach no longer works correctly. As described in Appendix A, the DIOBM structure that is embedded in the IRP will be needed as well. Moreover, it may not be sufficient to simply copy the DIOBM from the IRP to the IRPE. In particular, the irp$l_svapte may need to be modified if the DIOBM is moved.

The general approach to this change is to lock the buffer using the IRPE directly. This approach is shown in some detail in the following example:

irpe->irpe$b_type = DYN$C_IRPE;   (1)
irpe->irpe$l_driver_p0 = (int) irp;   (2)

status = exe_std$readlock( irp, pcb, ucb, ccb,   (3)
                           buf1, buf1_len, lock_err_rtn (4)  );
if( !$VMS_STATUS_SUCCESS(status) ) return status;

irpe->irpe$b_rmod = irp->irp$b_rmod; (5)
status = exe_std$readlock( (IRP *)irpe, pcb, ucb, ccb,   (6)
                           buf2, buf2_len, lock_err_rtn );
if( !$VMS_STATUS_SUCCESS(status) ) return status;