VDDR/2 - Base Virtual Device Drivers
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
|Virtual Device Driver Reference for OS/2|
|Part 1. Overview
Part 2. Virtual Device Drivers
Part 3. Reference Material
- 1 Base Virtual Device Drivers
- 1.1 Virtual BIOS Device Driver
- 1.2 Virtual CMOS Device Drivers
- 1.3 Virtual Direct Memory Access Device Driver
- 1.4 Virtual Diskette Device Driver
- 1.5 Virtual Hard Disk Device Driver
- 1.6 Virtual Numeric Coprocessor Device Driver
- 1.7 Virtual Keyboard Device Driver
- 1.8 Virtual Programmable Interrupt Controller Device Driver
- 1.9 Virtual Timer Device Driver
- 1.10 Virtual Parallel Port Device Driver
- 1.10.1 BIOS INT 17h Emulation
- 1.10.2 BIOS INT 05h Emulation
- 1.10.3 Printer Close Processing
- 1.10.4 Direct I/O Access
- 1.10.5 Share Access
- 1.10.6 Interrupt-Driven Data Transfers
- 1.10.7 Bidirectional Data Transfers
- 1.10.8 Enabling DOS Print TSRs
Base Virtual Device Drivers
The following list contains all the base virtual device drivers included with OS/2:
- Virtual BIOS device driver (VBIOS)
- Virtual CMOS device driver (VCMOS)
- Virtual direct memory access device driver (VDMA)
- Virtual diskette device driver (VFLPY)
- Virtual hard disk device driver (VDSK)
- Virtual keyboard device driver (VKBD)
- Virtual numeric coprocessor device driver (VNPX)
- Virtual parallel port device driver (VLPT)
- Virtual programmable interrupt controller device driver (VPIC)
- Virtual timer device driver (VTIMER)
Virtual BIOS Device Driver
The virtual BIOS device driver (VBIOS) contains the mechanism to initialize the Interrupt Vector table, BIOS data area, extended BIOS data area (on a PS/2* personal computer adapter ROM area), and the system ROM. It also provides virtual access to Programmable Option Select (POS) registers (on a PS/2 personal computer) and supports some of the DOS settings.
DOS Session Creation
When a DOS session is created, the virtual BIOS device driver is responsible for allocating and initializing the following areas in the DOS session's address space with the respective values from physical memory:
- Interrupt Vector Table
- BIOS data area
- DOS communications area
- Extended BIOS data area (on a PS/2 personal computer).
The virtual BIOS device driver is also responsible for mapping the system ROM and adapter ROM into the address space of the DOS session. The per-DOS session copy of the POS registers is initialized at this time.
The virtual BIOS device driver is responsible for Include/Exclude region support. The DOS setting MEM_INCLUDE_REGIONS gives the user an option to give more space to EMM/XMS. If the user knows that in a particular DOS session an adapter will not be used, then the linear region taken by that adapter can be given to EMM and XMS through MEM_INCLUDE_REGIONS. MEM_ EXCLUDE_REGIONS gives the user an option to restrict EMM and XMS from claiming a particular region. Both these options are provided through DOS settings. These DOS settings are only applicable at DOS session creation time.
At system initialization, the virtual BIOS device driver searches the region between the top of the DOS user space (RMSIZE) and 1MB to find all of the adapter ROM. Adapter ROMs that include the ROM signature will be found. In a normal DOS session creation (without any Include/Exclude properties specified), these linear addresses are mapped to corresponding physical ROM.
All the ranges specified in the DOS setting MEM_INCLUDE_REGIONS are taken out of the list used for mapping the linear addresses to corresponding physical ROM. As a result, MEM_INCLUDE_REGIONS is not mapped to physical ROM and it remains available to EMM or XMS.
For MEM_EXCLUDE_REGIONS, the virtual BIOS device driver reserves those regions and maps them to their corresponding physical addresses. This allows the user the ability to map adapter ROM that does not contain the ROM signature and adapter RAM.
Virtual CMOS Device Drivers
The virtual CMOS device driver consists of virtual support for the CMOS battery backed-up RAM, the Real-Time Clock (RTC) and the Nonmaskable Interrupt (NMI) disable logic. It provides virtual access to the address and data latches through virtual I/O ports. This component allows the majority of existing DOS applications that access its ports by direct access, or by normal BIOS calls, to operate without change.
The following functions are supported by the virtual CMOS device driver:
- CMOS memory access
- I/O port support
- Read time-of-day and date
- Real-Time Clock and interrupt access
CMOS Memory Access
CMOS Memory Access provides support for passive reads and writes to virtual CMOS memory. The CMOS portion of the CMOS/RTC can be read or written. The virtual CMOS memory is initialized to the contents of the physical CMOS memory (at the time of DOS session initialization) through the physical clock device driver, which is the physical device driver of the virtual CMOS component. Values are written to the virtual CMOS memory in a buffer local to the DOS session. Unlike the physical CMOS memory, however, the contents of the virtual CMOS memory are lost when the DOS session is terminated.
Input/Output Port Support
The virtual CMOS device driver component monitors all accesses to its two DOS session I/O ports. The two ports are a write-only address latch and a read/write data latch. The address latch port has two functions, NMI Disable and CMOS/RTC Device Address Selection. The data latch is a register for holding a byte being transferred to or from the CMOS/RTC device.
Disabling Nonmaskable Interrupts
The Nonmaskable Interrupt (NMI)-Disable portion of the the address latch can be set or reset by a DOS application. However, changes to enable or disable NMI are otherwise ignored.
Read Time-of-Day and Date
This function presents the correct seconds, minutes, and hours to an application reading the appropriate locations. This function also provides atomic access to all values to avoid reading the values during time transition.
Real-Time Clock and Interrupt Access
The Real-Time Clock consists of a time-of-day clock, an alarm interrupt, and a periodic interrupt. Accesses to the Real-Time Clock to change the time of day or the timing mode, or to set an alarm or periodic interrupt, are disallowed. The CMOS/RTC registers related to the Real-Time Clock are supported for read-only access. Because interrupts can only be supported through write access to the ports, Real-Time Clock interrupts are not supported.
The virtual CMOS device driver component does not emulate BIOS functions. Instead, it allows the existing BIOS functions to be used without change.
From the perspective of the DOS session, the virtual CMOS device driver component supports access to I/O address space only. Therefore, the following functions are not supported:
- Set Time-of-Day and Date
- Set Time-of-Day Alarm
- Set/Enable Periodic Interrupt
- Enable Update Interrupt
Virtual Direct Memory Access Device Driver
The virtual direct memory access device driver (VDMA) provides per-DOS session per-direct memory access (DMA) channel virtualization. In addition, the virtual DMA device driver provides the following:
- Serializes the DOS session's DMA requests on a per-DMA channel basis (but allows simultaneous requests on different DMA channels)
- Converts the DOS session's linear addresses to physical addresses, and handles all the data movement required
- Handles all the restrictions of a DMA chip
- Supports the enhanced DMA operations and commands of a personal computer
- Optimizes DMA virtualization on personal computers by using the enhanced mode
- Supports INT 4Bh - Function 81h virtual DMA services
- Supports virtualized DMA in auto-initialization mode
In addition to the above features, the virtual DMA device driver also synchronizes the operations with other virtual device drivers registered on different DMA channels. A virtual device driver for a piece of hardware, which uses a DMA channel, registers with the virtual DMA device driver. The virtual device driver informs these virtual device drivers before starting and stopping the DMA operation on their channels.
Virtual Diskette Device Driver
The virtual diskette device driver (VFLPY) intercepts applications that try to access the diskette drive directly or issue INT 13h calls. This virtual device driver also serializes and coordinates I/O operations between multiple DOS sessions.
Obtaining Physical Diskette Hardware Ownership
When the system first starts up, the physical diskette device driver owns the physical diskette hardware. All diskette accesses from the OS/2 applications go through the file system or the physical diskette device driver, and are eventually serialized into requests. Initially, the virtual hard disk device driver does not own the diskette controller, and it hooks all the diskette ports. It requests ownership from the physical diskette device driver when the DOS session accesses any diskette port, or when the virtual DMA device driver informs the virtual hard disk device driver that the diskette DMA channel has been unmasked. If the immediate ownership request is not successful, the DOS session is blocked until the physical diskette device driver calls back and grants the ownership.
Releasing Physical Diskette Hardware Ownership
Once the virtual diskette device driver has obtained the diskette ownership , it does not release ownership until the physical diskette device driver requests it, or the diskette motor is turned OFF.
Physical Diskette Interrupt Routing
Physical diskette interrupts are always routed to the physical device driver by the interrupt manager. If the virtual diskette device driver has the exclusive hardware ownership when the interrupt happens, the physical diskette device driver routes the event to the virtual diskette device driver, which simulates the interrupt to the DOS session.
Virtual Hard Disk Device Driver
The virtual hard disk device driver (VDSK) provides virtual disk support for multiple DOS sessions and supports access to the disk through BIOS (INT 13h) calls. Since BIOS accesses the hardware ports directly, the virtual hard disk device driver component overrides the BIOS by directly emulating INT 13h for hard disks. The virtual hard disk device driver component does not provide I/O port level access to the disk controllers. Access to hardware ports that are supported for the diskette drive, and BIOS INT 13h calls, are not emulated; instead, they are run from the actual BIOS. INT 13h support includes:
- AH=00h Reset diskette system
- AH=01h Status of disk system
- AH=02h Read sectors into memory (both diskette and hard disk)
- AH=03h Write sectors from memory (diskette only)
- AH=04h Verify sectors (both diskette and hard disk)
- AH=05h Format track (diskette only)
- AH=08h Get current drive parameters (both diskette and hard disk)
- AH=0Ch Seek
- AH=15h Get disk type (both diskette and hard disk)
- AH=16h Change of disk status (diskette only)
- AH=17h Set disk type (diskette only)
- AH=18h Set media type for format (diskette only)
The INT 13h emulator is also responsible for maintaining the diskette and hard disk areas of the ROM BIOS data area.
Typical steps of an INT 13h access are listed below:
- A DOS application accesses the disk through the INT 13h interface. The INT 13h call is trapped by the virtual hard disk device driver.
- A request packet is built and sent to the physical hard disk device driver . The DOS session is then blocked, waiting for the request to finish.
- Upon receiving the request packet, if the disk is currently busy, the physical hard disk device driver queues the request.
- When the request is completed, the physical device driver notifies virtual device driver, which unblocks the DOS session.
Because the virtual hard disk device driver component does not support register level accesses of the disk controller, all accesses to its registers are trapped and ignored.
Note: Timing-related copy protection can fail because real-time access is not guaranteed. Sector WRITE and FORMAT requests are not supported for hard disk. Sector WRITE and FORMAT operations are supported for diskette.
Virtual Numeric Coprocessor Device Driver
The virtual numeric coprocessor device driver (VNPX) provides virtual coprocessor (80 x 87) support for multiple DOS sessions. The virtual numeric coprocessor device driver coordinates exception and interrupt reflection for the real coprocessor. Machines with the 80386 B1 processor, or without a coprocessor, do not have coprocessor support.
Virtual Keyboard Device Driver
The virtual keyboard device driver (VKBD) consists of virtual support for the keyboard. It allows keystrokes to be passed from the keyboard to the DOS session and text to be pasted from another application into the DOS session as keystrokes. This virtual device driver also allows existing DOS applications that access the keyboard to operate without change. Such applications can access the keyboard through BIOS calls, access to the BIOS data area, or monitoring of the keyboard interrupt, and reading keystroke data directly from the I/O ports.
The virtual keyboard device driver addresses the following issues:
- INT 21h Access
- DOS applications can access the keyboard by opening the " CON:" (console) device, or by default standard input access.
- BIOS Access
- DOS applications can access the keyboard through BIOS INT 09h and INT 16h.
- I/O Port Access
- DOS applications can access the keyboard by reading and writing I/O ports 60h and 64h. This access is not restricted to reading scan codes, and can include other types of access (such as LED control).
- Data can be pasted from other OS/2 applications.
- Keystrokes are translated according to the current keyboard translation table and code page.
- Idle Detection
- DOS applications must not waste excessive CPU time when in input peek loops.
Levels of I/O Support
The various levels of support for the virtual keyboard device driver are as follows:
- BIOS support
- CON device driver support
- DOS support
- Idle detection support
- I/O port support
- Pasting support
Since the BIOS INT 16h service only references the BIOS data area for keystrokes, the BIOS continues to provide this service.
The BIOS INT 09h interrupt service routine, however, is emulated within the virtual keyboard device driver. When the INT 09h vector is invoked, the virtual keyboard device driver passes the character to the physical device driver, which translates the character according to the current translation table.
It is possible for an application or a DOS memory-resident program to hook the INT 09h vector. Often, such applications simply monitor keystrokes, and pass them on to the previously-hooked interrupt service routine. In this case, the virtual keyboard device driver emulation code still runs and translates scan codes according to the current translation table. Otherwise, if an application that has hooked INT 09h fails to pass the scan code on, then the scan code is not translated, or placed into the BIOS data area by the virtual keyboard device driver.
CON Device Driver Support
This support consists of allowing the virtual console device driver to be replaced. Although the default virtual console device driver. restricts keyboard access to BIOS calls, user-supplied drivers can access the keyboard through I/O ports or through the BIOS data area.
This support consists of keyboard access through the various INT 21h functions. In particular, this is support for access from the DOS emulation component. For compatibility, DOS calls the virtual console device driver to read keystrokes. This allows the virtual console device driver to be replaced without ill effect.
Idle Detection Support
DOS applications waste CPU time in a multitasking system when they peek for input in a loop. Idle conditions are detected when:
- The application is polling the keyboard using INT 16h in a loop
- DOS is polling in an input loop
- Repeated INT 28h calls are received from a DOS application
- INT 2Fh, AX=1680h yield calls are received
- DOS INT 21h, service 0Bh calls are received
I/O Port Support
The virtual keyboard device driver is responsible for supporting programs that access the keyboard ports directly. These ports provide access to data ports on the hardware that controls I/O to the keyboard. This support is provided primarily for applications that simply read the scan code directly from the port. However, other functions are possible, such as setting the key repeat rate. Repeat rates affect the entire system; per-DOS session repeat rates are not supported. Extended scanner functions, such as providing keyboard pre-controller translation, are not supported; such commands are ignored.
The virtual keyboard device driver supports two levels of pasting from the clipboard into a DOS session; fast pasting and slow pasting. In fast pasting support, characters from the clipboard are put directly into the BIOS buffer. For those DOS applications that get their key strokes from the BIOS key buffer (through INT 16h), fast pasting is adequate. For those DOS applications that hook INT 09h or INT 15h (AH=4Fh), key scan sequences are expected, which must be generated by the slow pasting mechanism.
In slow pasting, every character from the clipboard is reverse translated into scan sequence and can involve generating make-and-break scans of not only the character itself, but also the make and break of the shift keys in order to adjust the upper, lower, or control case of the character. It can even involve generating Alt+numeric keypad scan sequences for those characters, which cannot be directly typed on the keyboard (such as graphics characters or international characters).
Virtual Programmable Interrupt Controller Device Driver
The virtual PIC device driver (VPIC) is responsible for the virtualization of the 8259 Programmable Interrupt Controller (PIC) for multiple DOS sessions and for the simulation of interrupts to DOS sessions. Performance is a major requirement for hardware interrupt simulation. In this book, hardware interrupt and interrupt have the same meaning. Simulated interrupt, interrupt simulation, and hardware interrupt simulation all refer to the virtual PIC device driver sending an interrupt to a DOS session.
The virtual PIC device driver supports the hardware interrupt-related services needed by virtual device drivers and DOS sessions. The services include setting handlers to trap EOI and IRET events, simulating interrupts to DOS sessions, and handling PIC I/O accesses by DOS sessions. See Virtual Interrupt Services for a list of these virtual DevHlp services. The virtual PIC device driver maintains a per-DOS session virtual PIC state so that each DOS session appears to have its own independent 8259 Programmable Interrupt Controller. Provisions are included to demand page DOS sessions interrupt handling code. The virtual PIC device driver provides a DOS session with the following services:
- Virtualization of the 8259 PIC ports:
- -Separate master and slave PICs
- -Mask and unmask IRQ commands
- -Specific and nonspecific EOI commands
- -Read IR and IS register commands
- Hardware interrupts that can be be postponed until task time so that a DOS session can be paged
- Interrupts from an optional hardware adapter, which does not have a virtual device driver and a physical device driver, that can be simulated to a DOS application
The virtual PIC device driver provides virtual device drivers with:
- A high-performance mechanism to send hardware interrupts to DOS sessions:
- -Support for more than one virtual device driver to share an interrupt level
- -Support for a virtual device driver to regain control when a DOS session issues EOI commands, or when a DOS session executes the IRET at the end of the interrupt routine
- A mechanism for virtual device drivers to send a virtual EOI to the virtual PIC device driver
- A way to block until an interrupt is simulated
- A mechanism to query a DOS session's virtual IRQ state or status:
- -Masked or unmasked state (IMR)
- -Waiting to be sent to a DOS session state (IRR)
- -Executing DOS session's interrupt handler code state (ISR)
- -Pending interrupt routine IRET state
Hardware interrupt simulation is closely tied to the PIC virtualization. Virtual device drivers need a fast mechanism to call a DOS session's real- mode interrupt handler for a hardware interrupt. Because paging of DOS sessions (and therefore DOS session interrupt handlers) is required, simulated interrupts are delayed until the task-time context of the target DOS session.
Virtual Timer Device Driver
The virtual timer device driver (VTIMER) provides virtual timer support for multiple DOS sessions. This virtual timer device driver emulates the Intel* * 8254A Programmable Interval Timer.
The virtual timer device driver provides the following:
- Virtualization of timer ports to allow reprogramming of the interrupt rate and the speaker tone frequency
- Distribution of timer ticks to DOS sessions
- Maintenance of the timer tick count in the BIOS data area
- Serialization of Timer 0 and Timer 2 between the virtual timer device driver and the physical timer device driver
Virtual Parallel Port Device Driver
The virtual parallel port device driver (VLPT) consists of virtual support for direct hardware access to the three parallel ports (LPT1, LPT2, and LPT3), and for the printer-related BIOS entry points (Printer I/O INT 17h, Print Screen INT 05h). Existing DOS applications that access the parallel ports, either by direct access to the ports or by printer BIOS, operate without change. The VLPT provides the virtualization to allow multiple DOS applications to access virtual printer hardware simultaneously. This virtual device driver, in conjunction with the spooler, attempts to prevent multiple DOS applications that transmit data by using BIOS functions or direct hardware access, from intermixing output at the parallel port.
The virtual parallel port device driver consists of several sections:
- BIOS INT 17h Emulation
- BIOS INT 05h Emulation
- Printer Close Processing
- Direct I/O Access
BIOS INT 17h Emulation
One method DOS applications can use to send data to a printer is to use BIOS interrupt 17h. The VLPT emulates BIOS INT 17h and passes these requests through the file system to the physical parallel port device driver (PLPT) by using the system services VDHOpen, VDHWrite and VDHClose. See VDHOpen, VDHWrite, and VDHClose. These functions are not passed to the BIOS for processing.
The BIOS INT 17h emulation supports three functions:
- Print Character
- The Print Character function buffers single character requests in the virtual device driver buffer associated with each device in a DOS session. When the buffer becomes full, its contents are sent to the VLPT by using VDHWrite. If the device is not open, the VLPT issues VDHOpen to obtain a file handle and start a printer data stream. See VDHWrite and VDHOpen.
- The virtual parallel port device driver buffer is sent to the physical parallel port device driver by using VDHWrite. The printer data stream is closed by using VDHClose. See VDHWrite and VDHClose.
When the spooler is enabled, closing the data stream closes the spool file. Any subsequent printing will open a new spool file. The beginning of the spool file contains escape sequences to reset the printer to its power-on defaults. When the spooler is disabled, no initialization of the device takes place.
- Read Status
- The Read Status function returns the contents of the virtual device status register.
See #Printer Close Processing for the possible methods of closing a printer data stream opened with BIOS INT 17h.
BIOS INT 05h Emulation
The method used to send data from the display to the printer (LPT1) is to press the Print Screen key. DOS applications can also initiate a Print Screen function by issuing a call to a BIOS INT 05h function. The virtual parallel port device driver passes this request to BIOS for processing. The virtual device driver performs some special processing to prevent the INT 05h request from intermixing with an INT 17h print request to the same device. Also, two BIOS INT 05h requests cannot be performed simultaneously from within the same DOS session. The second print screen request is ignored.
Printer Close Processing
BIOS printer interrupts operate on a single-character basis, which can have a negative impact on printer and system performance. For this reason, the VLPT buffers BIOS print requests. When the buffer becomes full, print requests are sent to the file system to be spooled and printed. The size of the application's print request is rarely an even multiple of the VLPT buffer size. This causes the virtual device driver to provide methods of flushing the remaining characters in its buffer.
A virtual parallel port device driver's BIOS INT 17h buffers are flushed in one of four ways:
- DOS settings PRINT_TIMEOUT automatic close feature
- Ctrl+Alt+Print Screen key sequence (VDHPrintClose)
- Application termination
- DOS session termination
DOS Settings PRINT_SEPARATE_OUTPUT
The user can set the DOS setting PRINT_SEPARATE_OUTPUT to specify whether or not the virtual parallel port device driver should separate INT 17h output sent to the same device by two different DOS programs that are running in the same DOS session.
If set OFF, the VLPT will not open a new data stream each time the Program Segment Prefix (PSP) changes.
The user can set the DOS setting PRINT_TIMEOUT to specify the length of time in seconds that the VLPT will wait between occurrences of INT 17h before flushing its buffer. A setting of 0 (zero) specifies to wait indefinitely, that is, to never flush the buffer using the timeout mechanism. The PRINT_TIMEOUT mechanism flushes the buffer and closes the data stream automatically each time the DOS application stops printing by using INT 17h for the time specified.
Ctrl+Alt+Print Screen Key Sequence
After the DOS application has printed the entire file (issued INT 17h), the virtual parallel port device driver can be alerted to flush the remaining characters in its buffer by pressing Control+Alt+Print Screen. The virtual keyboard device driver calls VDHPrintClose (an exported virtual parallel port device driver entry point) to alert the virtual parallel port device driver that the key sequence has been pressed, and to flush the buffer. See VDHPrintClose.
Application and DOS Session Termination
The virtual parallel port device driver is notified when the application terminates or the DOS session is closed, and will flush the remaining characters in its buffer.
Direct I/O Access
The virtual parallel port device driver, at its initialization, registers an Inter-device Driver Communication (IDC) with the physical parallel port device driver. The VLPT requests exclusive access to the parallel port hardware through the VDD/PDD IDC when a DOS application interfaces directly with the hardware. Data transmitted using the direct I/O access method will bypass the spooler. Completion of exclusive access occurs when the key combination Ctrl+Alt+Print Screen is pressed, the application is terminated , or the DOS session is terminated.
Share Access is an option of the spooler that enables multiple DOS applications to simultaneously access the parallel port. The option is enabled by selecting the Share Access checkbox in the Parallel Port Settings dialog box found on the output page of the Print Object Setting Notebook.
Once enabled, multiple copies of DOS applications that access security devices attached to the parallel port can be started simultaneously. Use of this option turns OFF the serialization of accesses (the protection mechanism) to the parallel port.
One DOS application can overwrite another that is using the parallel port, causing the latter application to fail.
Interrupt-Driven Data Transfers
The virtual parallel port device driver reflects virtual hardware interrupts to applications executing in a DOS session.
Bidirectional Data Transfers
The extended mode of the PS/2 personal computer parallel port allows the port to be used as a bidirectional eight-bit parallel interface. This capability is supported by the virtual parallel port device driver when DOS applications directly access the parallel port hardware.
Enabling DOS Print TSRs
The DOS operating system implements its printing function by passing print requests from its INT 21h interface to the single character BIOS INT 17h interface. Many Terminate-and-Stay-Resident (TSR) DOS applications hook into the INT 17h vector chain to perform additional processing (such as font support, spooling, and character set downloading) before sending the print data to the device attached to the parallel port. They expect all print data to pass through to the INT 17h interface.
Since these additional functions are now provided by the OS/2 operating system and since BIOS INT 17h is not performance-sensitive, the operating system passes INT 21h print requests as buffers through the file system to the physical parallel port device driver for transmission instead of sending print requests as single character requests to BIOS INT 17h. The gain, by this approach, is the increased throughput and better utilization of the device attached to the parallel port. The trade-off has been the inability of some DOS TSR applications to perform their print functions.
LPTDD.SYS is a DOS device driver that can be installed to convert DOS session INT 21h print requests to INT 17h and thereby enable this class of DOS TSRs. By using the "DEVICE=" statement in the CONFIG.SYS file or the DOS_DEVICE option in DOS Settings, the device driver can perform the INT 17h conversion either in all DOS sessions, or in individual DOS sessions corresponding to the two methods, respectively.