bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/27/87)
Recently I was flamed for sloppy use of the word "device". Within the
Amiga system that word has no less than three (3) distinct meanings. I
pledged to write a glossary to aid in future understanding. And, while on
hold this morning, I did.
With this glossary I have two options; perpetuate the confusion, or do
something different. For the final glossary I'll do what the net votes on.
For now, here are the glossary entries relating to DOS, as proposed. Be
forewarned that I took liberties whenever DOS's use of terminology was
muddled.
----------------------- Amiga Glossary ----------------------------
AmigaDOS
Amiga Disk Operating System. Strictly speaking, the part of the Amiga
operating system that controls the file system. Unlike MS-DOS, there
is more to the Amiga operating system than just DOS.
Workbench CLI Programs
\ | /
\ | /
\ | /
\ | /
\ | /
AmigaDOS ;DOS level
/ | \
RAM: DF0: HD0: ;FILE SYSTEM level
| | | ;(managed by handler processes)
memory disk hard disk ;DEVICE level
drive drive ;(managed by device drivers)
Programs may often bypass the DOS level by sending a packet directly to
the proper handler process.
DEVICE, EXEC
Usually a task that that talks directly to some piece of hardware. The
"keyboard.device", for example, reads the keyboard then tells the rest
of the world about it. The "trackdisk.device" is an example of a
device that can have multiple units.
Programs communicate to devices with IO requests, a form of inter-task
communication.
The standard devices are: timer, trackdisk, keyboard, gameport, input,
console, audio, narrator, serial, parallel, and printer.
With each hard drive, SCSI interface, or extra serial port, you will
probably get another exec device.
DEVICE DRIVER
The actual code that a device executes.
FILE SYSTEM
A place to store files.
HANDLER
On the Amiga, the code that manages a file system. Handlers often live
in the L: directory when not in use.
LOCK
An AmigaDOS structure that prevents multitasking programs from stomping
on shared files.
PACKET
An AmigaDOS specific message. All DOS activity is actually carried out
with a packet sent to the proper handler.
-----------------------------------------
Opinions welcome. Asbestos installed.
BTW: This file was munched twice by XMODEM, it did not notice the errors!
(My version of VT100 does not support XMODEM CRC, but I wish it would!)
-----
|\ /| . Ack! (NAK, EOT, SOH)
{o O} .
( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
U "When it's you against the world, back the world." scotty@l5comp.UUCP (Scott Turner) (08/02/87)
In article <8707271817.AA17537@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > >Recently I was flamed for sloppy use of the word "device". Within the >Amiga system that word has no less than three (3) distinct meanings. I >pledged to write a glossary to aid in future understanding. And, while on >hold this morning, I did. In understanding the Amiga I've found it helpful to adjust my "viewpoint" from time to time. Namely the Amiga's documentation is written as "From the outside looking in". It's often helpful to crawl inside and look out. When you do that the whole handler/device structure becomes clear. First, names of devices end '.device', and handlers end with 'handler'. Handlers live in L: and .devices live in DEVS: (unless they live in ROM :). AmigaDOG can only talk to the outside world through "packets". Packets are Exec messages with various fields tacked on to allow passing parameters and results back and forth. (See includes/libraries/dosextens.{h,i}) When you open "dos.library" and then call a routine, the routine usually converts the call into a packet and passes it along. AmigaDOG can NOT talk to devices, they don't speak packet. To get to a device you must talk packet to a "handler". This handler then talks to the .device. The .device then talks to the actual hardware. The end result of the above is that dos.library is more of a "packet router" than an actual disk operating system. The actual "brains" that make AmigaDOG look like a disk operating system are in the handlers. There seem to be several basic handlers: 1. Generic disk handler. This handler is chiefly responsible for the tag "dog", it's a pretty stupid handler in terms of how it handles using the disk resources given to it. This handler can go under MANY names, most often it is seen as "DF0:" but can also show up as "DH0:" etc... Through the use of mount you can call it anything you want. The 0's in the names above are NOT required! You can use mount and call a disk handler 'ThisIsNeat:'. This handler is responsible for ALL aspects of file handling on a disk device. This handler is what defines what an Amiga disk looks like in terms of where and how data are stored on disk drives. It could be replaced/augmented with a messydos handler that laid data out on disks just like messydos and we could read/write disks made by PC's. 2. Generic character handler. This is the handler used to drive the {serial,parallel}.device. Unlike the brain damaged disk handler this handler seems to be fairly efficent. Unlike the disk handler this handler doesn't have to manage files etc... All it does is translate packets coming in into .device messages which it then sends onto the actual device driver routine. 3. Good ol' ram:. Unlike the previous two handlers this one lives on disk, the above live in the ROM. This handler manages a linked list of ram blocks to make them act like a ram based disk drive. This handler is also unique in that it "violates" the usual "handler drives .device" rule. This handler does NOT have a matching device driver. Inside this handler we have a FULL file system! There's code in here to open/close/create/delete files. Most other computers use a simple "device driver" and let the same code that manages the disk driver drive the ram device driver. The ASDG VD0: is an example of this kind of setup. The ASDG VD0: is a device driver that runs under the disk handler. VD0: COULD be re-written as a handler, but it would then have to support a file system rather than just sit back and move blocks of data back and forth at the request of a handler. The VD0: would then also run faster. Maybe Perry is already hard at work on VD0 II? (Another interesting point, has anyone tested the 1.3 hard disk handler with VD0? Should improve VD0's performance as well...) 4. Console handler. The difference between this handler and the character handler is that this handler can take filenames passed to it and translate them into calls to intuition.library to create windows. When you open CON:10/10/100/200/TickTock the console handler takes the "path" to file TickTock and uses it to open a window and gives that window the name TickTock. In effect the console handler is a "file system" handler to manage windows. Of course in the console's file system files are always located 4 steps down a path. :) (You can't open CON:TickTock) When the mountlist/mount are used to "mount" a device some internal logic decides what handler to assign to manage that device since AmigaDOG can't talk directly to it. I haven't taken mount apart so I don't know what the rules are (and C-A hasn't seen fit to tell me either :) but if all you do is mount a device there seem to be only two choices. You either get the generic disk handler or you get the generic character handler. I think the trick hinges on wether you specify any of the disk based parameters "Surfaces, Reserved, Interleave" etc. If none of those show up mount assigns the device to the character handler. Otherwise the device is assigned to the disk handler. I've tried, and it does work, making a mountlist entry that specifies a handler AND a device. In this case your handler is started and passed the device which it is supposed to use. For example if you had a messydos.handler you could have an entry for it that would also include a reference to trackdisk.device (or scottdisk.device). This would then mount a handler that could talk to messydos formatted media through trackdisk.device. All the confusion comes when we step back outside again. Outside everyone points at DF0: and says "That's a disk device". As with pill bottles, AmigaDOG can't leap up and say "HEY! That ain't a disk device, it's a disk handler!" But have no fear, the AmigDOG does know the difference. :) Here follows another view on the diagram Bryce made: AmigaDOS(tm) Amiga Disk Operating System. Strictly speaking, the part of the Amiga operating system that controls the routing of packets to/from handler processes. Unlike MS-DOS(tm), there is no filesystem at this level. Workbench CLI Programs-+ \ | / | \ | / |<--Lowlevel communication path \ | / | \ | / | \ | / | AmigaDOS | ; dos.library level / | \ | RAM: CON: SER: DF0: <-+ ; handler process level (each column is : RAW: PAR: DH0: ! ; a different handler. DF0 & DH0 etc : ! ! ! ! ; use the same handler.) : ! ! ! ! : Device drivers <-+ ; Device driver level : : : Memory Various devices <-+ ; Device level (actual hardware) KEY | = Uses a "packet" ! = Uses a "message" : = Uses direct access Programs may often bypass the DOS level by sending a packet directly to the proper handler process. It is also common to bypass the handler process level and send messages directly to the device drivers. It is of course possible to bypass EVERYTHING and talk directly with the actual hardware, but this is NOT recommended. AmigaDOS is a trademark of Commodore-Amiga Inc. MS-DOS is a trademark of Microsoft Inc. Scott Turner is NOT trademarked so you can use it without fear (for now). Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan "Pirated software? Just say *NO*!" S. Turlkd.