[ont.micro.mac] Interfacing other disk to a mac

info-mac@utcsrgv.UUCP (info-mac) (05/08/84)

Date: Mon 7 May 84 20:30:05-MDT
From: Randy Frank <uw-beaver!FRANK@UTAH-20.ARPA>
Subject: Interfacing other disk to a mac
To: info-mac@SUMEX-AIM.ARPA

I just attended a Mac developer's seminar put on here by Andy Hertzfeld of
Apple.  I (think?) that these are being put on for the various consortium
schools (has anyone else been to one?)

It was very worthwhile, as much for "fokelore" as for hard information; if
you're offered the chance to attend, I'd recommend it.

Anyway, one of the most interesting aspects was gaining an appreciation of the
entire driver/file system structure, and how the design makes interfacing other
disks or file servers easy.

Basically, as I understood it, both the generic disk driver and file system
driver, in addition to their normal (Apple supplied) routines have "exits"
built-in, at appropriate places, for other (non-Apple supplied) versions of the
routines for non-Apple disks.  It's designed in such a way that the disk can
either be "dumb" (analogous to the existing floppy) where the disk can only
return sectors, or "smart" in the sense that the disk is really a "file server"
which is passed file names and logical read/write requests in which case the
Mac doesn't do directory processing locally.  Apple's assumption for "big" hard
disks is that they will be of the "smart" variety.  For the Sony floppy, the
Mac caches the entire directory in memory, since the memory requirements are
nominal (they stated about 300 bytes).  However, for a large hard disk sitting
on one of the 422 ports, the assumption is that it is of the "smart" variety
which is passed logical requests so that the Mac doesn't need to process
locally the directory information.

What is interesting about this approach is that it would seem to make using
"big" host computers as file servers a relatively easy task, although
admittedly you'd be constrained by typical serial line rates of the host (e.g.,
19.2 Kbit/sec) - the problem is the typical hosts - vaxen, 20s, etc. - not the
Mac.  However, for bulk file storage this may not be as serious a problem.
What's fantastic about this approach is that above the level of the file system
such a server looks identically to a local disk; files on the host server
appear as icons, and the host appears as just another disk.

The seminar didn't go into any more details.  However, I intend to follow up
this information and see where it leads.  It was clear from the presentation
that Apple gave a great deal of thought about handling a wide variety of disks
and file servers cleanly and uniformly, and that someone interfacing a "brand
x" disk is definitely not at a disadvantage to Apple in terms of interfacing
cleanly and uniformly to the Mac os.
-------