Topic : TOS - The Operating System Author : Version : tos.hyp (December 19, 2008) Subject : Programmieren/Atari Nodes : 3010 Index Size : 93790 HCP-Version : 5 Compiled on : Atari @charset : atarist @lang : @default : Title @help : @options : +g -i -s +x +zz -t4 @width : 70 View Ref-File11.5.16.1 General remarks about MagiC's XFS-concept TOS GEMDOS was until now the most conservative part of the MagiC operating system. For network drivers, practically all DOS calls, including Pexec, had to be recreated without being able to intervene at a deeper level. In Mag!X 1.x (as in TOS) the DOS was not even reentrant because a statically constructed stack was used. In MultiTOS/MiNT the problem is circumvented in such a way that a virtual system is laid over the GEMDOS which takes care of all higher management tasks, can incorporate other filesystems and uses GEMDOS only as a dumb filesystem driver. An advantage of this solution is its great flexibility and extendibility, but a decided drawback is the towering overhead when using the 'normal' DOS filesystem. But this is just the one that is utilized most frequently. In addition, the GEMDOS filesystem can gain no functionality, comfort or speed with the use of MiNT, since the old routines only execute with additional overhead. File-system accesses under MiNT are therefore generally not reentrant, i.e., as under MS-Windows, every floppy disk access paralyses the whole computer. A further property of MiNT is the attempt to undertake functions that all filesystems have in common in the kernel. Although this leaves the filesystem drivers (MiNT-XFSs) compact, due to the Inode-oriented format of the kernel functions an unfavourable structure is forced on the file drivers in some circumstances; in addition, generally many calls of the filesystem driver are required for one DOS call. Finally the MiNT kernel itself is very long, but to a large extent lies fallow as long as no filesystems other than DOS are in use. Under MagiC a different approach was chosen, which included rewriting all GEMDOS functions from the ground up, including the low-level ones for the sector buffering, and to carve them up into three, four or five layers in which one can intervene from the outside (with loaded- in drivers). A side-effect resulted in an extension of the DOS file system functionality and an additional filesystem on the logical drive U:. The whole concept inclusive of accesses to the DOS filesystems is reentrant and runs in the background. Thus it is possible to amend files on drive A: without markedly slowing down the computer during floppy disk accesses. Despite this MagiC has till now grown only by 10kB. Compared to MiNT, more functions were offloaded into the file system drivers, and while this makes them longer, it gives them the possibility of executing the functions much more efficiently. Also, the DOS filesystem has become somewhat faster rather than slower. Although realized completely in Assembler, we are dealing with an object-oriented operating system with virtual functions and multi- level heredity. A file descriptor (FD), as used by the kernel and made available by the XFS, is an object with special data and functions. But the XFS realizes also a derived object with further data fields and functions. Finally the DFS subdriver of the DOS_XFS must in turn accommodate further functions and data in the FD and extrapolate the class further. Things look exactly the same with the DMD (drive medium descriptor). The kernel requires only a few statements, but the lower layers appreciably more, though always different ones. The layers in detail: 1. The DOS kernel. This lies in MagiC itself and is called directly by user programs via TRAP #1. It contains modules for memory management, for process management and for file management. The latter has the following sublayers: 2. The filesystem (XFS = eXtended File-System). Its construction is basically different from a MiNT-XFS, but fulfills the same purpose. MagiC for Ataris contains only a single XFS, the so- called DOS_XFS; others can be incorporated. The Macintosh version (MagiC Mac) contains a Mac-XFS in addition. Specifically this filesystem again makes use of subdrivers: (a) A DOS filesystem (DFS) is called up by DOS_XFS. This only contains the file functions, while the directory management is essentially taken on by the DOS_XFS. MagiC contains directly two DFSs. One for drive U:, a second for the FAT filesystems that lie on BIOS drives. More DFSs can be incorporated. The effort for a DFS is appreciably lower than for an XFS, as many functions are performed already by the DOS_XFS. The vital prerequisite is a DOS- conforming directory structure (with 32-bit entries and filenames in the 8+3 format). The kernel itself does not come into contact with the DFS but controls it transparently via the DOS-XFS. 3. The file drivers (MX_DEV), which essentially take care of file reading and writing operations. They are created and managed by the XFS, but with functions such as Fread and Fwrite called directly by the kernel, which accrues extremely low overheads. The DOS_XFS actually contains only one file driver. This handles the updating of the directory at write accesses, for instance, and in turn calls a subdriver (MX_DDEV). (a) The subdriver MX_DDEV is only called by the DOS file driver of the DOS_XFS filesystem. The user can incorporate custom MX_DDEVs via the directory U:\\DEV. The kernel itself does not come into contact with the subdrivers. Notes: . In contrast to MiNT, U:\PROC, U:\DEV etc. are not their own file systems but simply just subdirectories of the DFS for drive U:. Depending on the subdirectory, the U-DFS creates various file- types and -drivers. As the control of the directory is encumbent on the DOS_XFS, write accesses to a workstation, for instance, are logged in the directory by the file date-stamp. This even goes so far that a write access to the root of drive A: will alter the file date-stamp of U:\A automatically. Devices, pipes and shared memory blocks can be moved, deleted or renamed. Symbolic links can be created in all directories of drive U:; for instance, with 'ln -s U:\CON U:\CONSOLE' one can create an alias for the device file CON. One can also create empty files simply, though not folders since the drive U: has no memory allocated to it. . In contrats to MiNT, U:\ is not its own special filesystem. One just has to respect that only symbolic links can be created. The directories U:\A etc. are simply symbolic links, which can also be removed or renamed. . All directories of U: are restricted to 32 entries at present . The construction of all internal structures and the fast register- based parameter passing and return requires an implementation of all filesystems and drivers to be written in Assembler, at least for most of the functions . The construction of the MX_DDEV file driver has changed since MagiC V2.10. The sample driver DEV_LPT1 may not be used under MagiC V3.00 and higher. Actually the concepts have stayed the same, only a few constants have changed. A new sample driver is not yet available (at the time this was written). See also: MagiC's XFS-concept Test for pipes