The program is intended to provide an initial representation of disks which can be extended and improved; see the suggestions for improvements later in this document.
The slots in the disk-geometry object are used to store various information as follows:
Note that not all of these are used in the program as it stands (except when it comes to printing out details of an instance); however they exist to make it easier to write extensions to the program, as well as to serve as examples.
Typically, a map will divide a disk into a maximum of 7 slices; slices are numbered from 0, with slice 2 (by convention and for historical reasons) being used to reference the whole disk.
A possible partition map therefore for a disk with a total of 17660 usable cylinders might look like this.
Slice Start Cylinder End Cylinder # of Cylinders
0 0 130 131
1 131 228 98
2 0 17659 17660
3 229 749 521
4 0 0 0
5 750 847 98
6 848 2668 1821
7 2669 17659 14991
In this map, the disk is divided into 6 consecutive slices: slices 0, 1, 3, 5, 6 and 7. Slice 2 is the whole disk, and slice 4 is not needed: note the convention of specifying both start cylinder and number of cylinders as 0 to indicate an unused slice. Note also that only the start cylinder and number of cylinders is needed to specify the extent of a slice completely: the end cylinder is included in this example for clarity.
The slots in the disk-partition object are as follows:
The slots of disk are as follows:
To define a new instance of disk, call (define-disk disk-name geometry-name partition-name). If no geometry or partition objects exist with the given names, new ones are created with the names provided. All three name arguments are optional; if a name isn't provided, then the macro will create new instances.
New instances of disk-geometry and disk-partition are created using macros define-disk-geometry and define-disk-partition respectively. All three defining forms will prompt the user to supply necessary information for slot values if it is needed and not provided as arguments; some elementary sanity checks on the data are also carried out using after methods on initialize-instance.
There are also output routines, such as the generic function print-details, which prints out the slot values for a disk-package-object.
The program calls internal functions such as map-over-geometry-list and get-geometry etc. to access instances of sub-classes of disks-package-object.
If similar functionality were provided through external generic functions specialised on these sub-classes, it would probably be useful in itself, as well as providing a more general and extensible mechanism. The program could therefore be improved by replacing these functions with improved generic functions and methods, and exporting these.
The output routines could also be improved or replaced. One possibility is to provide output routines which use graphics routines to print out more helpful representations of disks, partition maps and so on.
As it stands the program will let you define more than one instance of a given class with the same name, but e.g. define-disk will only look up the LATEST definition with a given name. You could easily improve on this behaviour.
Currently there are provided only the basic subclasses disk-geometry, disk-partition and disk. These themselves could be subclassed, e.g. to define a hierarchy of physical disk types under disk-geometry, or a class of disks with a particular geometry and a default partition map. A standard partition map could be implemented. One further possibility is to define a default map as the value of a slot in disk-geometry; then a specific instance of disk either uses the default map or replaces this with its own map. If you do decide to extend the hierarchy, consider carefully the effect on the defining forms provided.
There are currently no functions to help the user define a partition map, which requires a bit of arithmetic - an ideal task for a computer. What about implementing an additional option to print-details which provides the equivalent disk space in megabytes (which is what system administrators are more interested in) for partition maps?
And what about implementing a function which allows the user to designate one slice as the "free hog" and have it use all space which is not taken up the by the rest? How about providing a function which aids the user in defining a map by printing out running totals - this could allow the user to enter sizes in cylinders or (approximate) megabytes? There are many other possibilities...
Author: Gail Anderson (ga@cley.com), Cley Limited. Copyright 1999-2003 Cley Ltd. & Franz Inc.