This chapter is only interesting for those who want to port mtools to an architecture which is not yet supported. For most common systems, default drives are already defined. If you want to add default drives for a still unsupported system, run config.guess, to see which identification autoconf uses for that system. This identification is of the form cpu-vendor-os (for example sparc-sun-sunos). The cpu and the os parts are passed to the compiler as preprocessor flags. The OS part is passed to the compiler in three forms.
All three versions are passed, if they are different.
To define the devices, use the entries for the systems that are already present as templates. In general, they have the following form:
#if (defined (my_cpu) && defined(my_os)) #define predefined_devices struct device devices[] = { { "/dev/first_drive", 'drive_letter', drive_description}, ... { "/dev/last_drive", 'drive_letter', drive_description} } #define INIT_NOOP #endif
"/dev/first_drive" is the name of the device or image file representing the drive. Drive_letter is a letter ranging from a to z giving access to the drive. Drive_description describes the type of the drive:
ED312
HD312
DD312
HD514
DD514
DDsmall
SS514
SSsmall
GENFD
GENHD
GEN
ZIPJAZ(flags)
Flags
are any special flags to be passed to open.
RZIPJAZ(flags)
Flags
are any special flags to be passed to open.
Entries may be described in more detail:
fat_bits,open_flags,cylinders,heads,sectors,DEF_ARG
or, if you need to describe an offset (filesystem doesn't start at beginning of filesystem)
fat_bits, open_flags, cylinders, heads, sectors, offset, DEF_ARG0
fat_bits
open_flags
cylinders,heads,sectors
offset
Definition of defaults in the devices file should only be done if these
same devices are found on a large number of hosts of this type. In that
case, could you also let me know about your new definitions, so that I
can include them into the next release. For purely local file, I
recommend that you use the /usr/local/etc/mtools.conf
and
~/.mtoolsrc
configuration files.
However, the devices files also allows to supply geometry setting routines. These are necessary if you want to access high capacity disks.
Two routines should be supplied:
static inline int get_parameters(int fd, struct generic_floppy_struct *floppy)This probes the current configured geometry, and return it in the structure generic_floppy_struct (which must also be declared). Fd is an open file descriptor for the device, and buf is an already filled in stat structure, which may be useful. This routine should return 1 if the probing fails, and 0 otherwise.
static inline int set_parameters(int fd, struct generic_floppy_struct *floppy) struct stat *buf)This configures the geometry contained in floppy on the file descriptor fd. Buf is the result of a stat call (already filled in). This should return 1 if the new geometry cannot be configured, and 0 otherwise.
A certain number of preprocessor macros should also be supplied:
TRACKS(floppy)
HEADS(floppy)
SECTORS(floppy)
SECTORS_PER_DISK(floppy)
BLOCK_MAJOR
CHAR_MAJOR
For the truly high capacity formats (XDF, 2m, etc), there is no clean and documented interface yet.
Go to the first, previous, next, last section, table of contents.