This section presents information on converting XENIX System V /386 device drivers to UNIX System V /386 device drivers.
In UNIX System V /386, the COFF and x.out 286 binaries are supported by the /bin/i286emul and /bin/x286emul user-level emulators. i286emul and x286emul trap system calls issued by a 286 program and either handle the system calls internally or perform necessary argument conversions before issuing a 386 system call. Therefore, the XENIX System V /386 device driver code that was used to support system calls from a 286 binary is no longer necessary.
In Release 3.2 of UNIX System V /386, the kernel support routines avail-able for device drivers handling 286 system calls [for example, IdtallocO, IdtfreeO, cvtointO, and cvtoaddrOl are provided as stubs to help facilitate compilation. These stubs will be removed in a future release of UNIX System V /386.
Programmers should keep the following information in mind when converting XENIX System V /386 device drivers to UNIX System V /386 device drivers:
• All XENIX System V /386 include lines that use the form
#inc1ude II •• /h/<file> II must be changed to
#inc1ude IIsys/<file> II
• The UNIX System V /386 Software Generation System (SGS) does not define the M-.I8086, M-.I286, or M-.I386 symbols. Instead, the i8086, i286, and i386 symbols can be used for native development.
• UNIX System V /386 does not support the near and far keywords. All references to near and far should be removed.
DEVICE DRIVERS 3-77
• In UNIX System V /386, the b_paddr field has been replaced with the b_un.b-addr field, which stores an address as a kernel virtual address.
In XENIX System V /386, the b_paddr field of the but structure stores an address as a physical address. All references to b_paddr should be changed to b_un.b_addr. Where appropriate, the ktopO macro should be used to convert the address stored in b_un.b-addr to a physical address.
• In UNIX System V /386, the b_blkno field of the but structure stores block numbers in units of 512 bytes. In XENIX System V /386, b_blkno stores blocks in units of 1024 bytes. Be sure to examine and convert all references of b_blkno to the units expected by your device driver.
• In UNIX System V /386, all block devices are required to have an xxprintO routine. The following example shows an xxprintO routine for a floppy diskette device driver:
flprint (dev, str) dev_t dev;
char *str;
{
}
ann_err (CE_l-DI'E, "%8 an floppy diskette unit %d, minor %d", str, unitbits (dev), minor(dev));
• All XENIX System V /386 device driver references to the cmos.h include file should be changed to sys/cram.h.
• The use of the physioO routine in UNIX System V /386 is slightly dif-ferent than in XENIX System V /386. In UNIX System V /386, the read and write routines first call the phyckO routine to validate the requested transfer; physio() is then called with a pointer to the device driver's xxbreakup() routine. xxbreakup() then calls the system breakup routine [either dma_breakupO or pio_breakup()] with a pointer to the device driver's xxstrategy routine. In XENIX System V /386, a driver's read and write routines called the physio() routine with a pointer to the driver's strategy routine (possibly with B_ TAPE set).
3·78 ISDG
The following example illustrates the UNIX System calling conven-tion:
flbreakup(bp) struct but *bp;
{
int flstrategy( ) ;
}
}
register int size;
size = flblktosec(flsize[sizeindx(dev)]);
/* size in sectors */
if (physck(size, B_READ))
physio(flbreakup, NULL, dev, B_READ);
• In UNIX System V /386, the user structure no longer contains the u-cpu field. A new field in the user structure, 11-lenv, contains the same information as u-cpu in bits 16-23.
• UNIX System V /386 calls the open, close, read, write, and ioctl rou-tines with the entire device number. XENIX System V /386 calls these routines with the minor device number. When converting XENIX Sys-tem V /386 device drivers, be sure to mask off the major portion of the device number only if the minor number is desired. This can be done using the minorO macro.
• After all device driver halt routines are called (those defined in the array io-halt[ ]), interrupts may be turned on again. If the UNIX Sys-tem V /386 device driver is used to control hardware, its halt routine should ensure that no interrupt is pending.
DEVICE DRIVERS 3-79
• In UNIX System V /386, the disksortO routine uses the b-sector field of the but structure to sort requests. In XENIX System V /386, disksortO uses the b_cylin field of the but strudure to sort requests. By using the b-sector field (which is a 32-bit field) better resolution can be obtained over the b_cylin field (which is a 16-bit field).
• UNIX System V /386 does not support the XENIX System V /386 mapptovO routine. Instead, the mappagesO routine should be used. The mappages() interface is shown below:
nappages (begmapaddr, length, ~)
caddr_t begmapaddr;
int length;
paddr_t begphysaddr;
Often, XENIX programmers did not use the ktop() macro to convert virtual addresses to physical addresses (for example, in the first call to copyio(), which expects a physical address) because in XENIX physical addresses are equivalent to virtual addresses. In UNIX System V /386, programmers can-not make this assumption; they must use a physical or virtual address where needed using the proper conversion macro where appropriate.
ISDG
4 Porting
Porting
Programming Techniques Portability Restrictions Input/Output Devices Utilities Set
System Calls Memory Space
Tunable System Parameters Absolute Memory Addresses Absolute Path Names System Header Files Sign Extension Adding New Features
PORTING 4-1 4-1 4-2 4-2 4-3 4-3 4-3 4-3 4-4 4-4 4-4 4-4 4-6
Portability is the ease in which applications or operating systems can be adapted to run on machines other than the ones they were designed for.
This chapter focuses on techniques and restrictions that should be considered when porting from one machine to another.