I worked for Apple Computer from July 1988 to March 1997, mostly trying to
teach them about things Internet while also maintaining their Internet
connectivity & security. It was fun while it lasted. While I was there, I
started going to the Apple WWDC each May, ostensibly to support a "terminal
room" where Internet access and AppleLink access could be had at the
conference, but I also went to get more contact with Apple developers and
hear more formally what was going on at Apple (internal communications in
that company have always been awful).

This year, a friend of mine who still works at Apple invited me to go to
WWDC because he had some tickets to hand out to people he thought it would
be good to have there, and because I'm involved with NetBSD. Normally it
costs $1,500 (ouch!). Herewith, my notes from that conference:

FireWire

Apple is making a push on FireWire (IEEE-1394), a 400Mb/s hot-pluggable
serial bus. Every Blue & White G3 desktop has it built in, and it will
appear in some future model of PowerBook, too. Sony is also including this
on their systems as the "iLink". There will be 800Mb/s FW "as soon as
silicon appears."

There is enough power on the FW to power small devices; their demo was to
plug in a portable disk drive (in a safety-orange and yellow case) from VST
to the FW, it spun up, and appeared on the desktop of the system. They
double-clicked on the disk, and there was a QuickTime video there. They
fired that up, and then unplugged the drive from the FW. The video stopped,
and a dialog box popped up that more or less said, "the disk on the FW went
away - please check the cables and power to put it back." They plugged it
in again, it spun up, and the movie picked up where it left off. The drive
was totally powered by the FW in this case, but VST had the smarts to have
an external power connector too, because PowerBook FW will *not* have
sufficient power on it to power external devices.

FW can be used to talk to disks, scanners, and so on, using SCSI Bus
Protocol-2 (SBP-2). This is more or less a tunnel for disks to start with;
there will be "native" FW disks later on, which are under development by
IBM and Seagate.

FW is used by Digital Video (DV) cameras for both content transfer (i.e.
playback & record), and device control (e.g. a window with command buttons,
play, stop, rew, FF, etc, on your system can control a camera on FW).

FW can be used for MIDI with the mLAN protocol, supported by Kawai & Roland.

Sony is also selling FW for a home A/V interconnect with the HAVi (Home
Audio/Video interconnect) protocol.

FW can also be used for IP networking; there is an IETF frame protocol
standard in process now which Apple will support; they don't currently plan
to do AppleTalk for FW. A gent from the Department of Physics at UCLA asked
Apple about using FW for computing clusters, and got pointed at the IP
interface stuff.

Web sites:
	http://www.1394ta.org/
	http://www.apple.com/firewire/

Mailing list:
	firewire@isg.apple.com

There will be a MacOS 8 Software Developer's Kit (SDK) on the Apple web
site soon (if not already). There will also be some support for FW on MacOS
X, it will be in the "I/O Kit".

The major issue for NetBSD here is implementation and support of hot-swap;
something that UNIX is not designed for, but that we need to do for PCMCIA,
USB, and now FireWire. Secondary issue is that FW supports isochronous
protocols (i.e. guaranteed delivery of bits on the tick of a clock) and
this means we need  device drivers with bounded-time interrupt response
latency (i.e. guaranteed response time).

Tertiary issue is implementation of the various protocols for devices that
can live on FW; some of that has to live in the kernel (e.g. SBP-2), and
some of it will likely be what Apple likes to call "a third-party
opportunity."


KeyChain API

Apple has a keychain API that is an implementation of the CDSA framework
(deplored by the crypto people I talked to as being pretty awful) for
X.509v3 certificates, cleartext passwords, etc. The goal is "single network
login" - the Holy Grail of useable network security.

The crypto modules underneath the API have to be crypto-signed by Apple to
run (this is how it's exportable; Apple will not sign strong crypto - same
as Microsoft in this regard), but since the OS has no memory protection,
this will be easy to circumvent. Also, this puts the decoded keychain in
jeopardy from a rogue program, so this whole thing isn't very safe to use
under MacOS 8. MacOS X might be another matter.

The CDSA stuff can be found on the OpenGroup web page:

	http://www.opengroup.org/


MacOS X "I/O Kit"

This is derived from NeXT's driver kit, and is a collection of SDK's for
"extensions" can be used for PCI, SCSI, other storage, plus some libraries
for I/O registration, an I/O Catalog, and Power Management.

It used to all be in Objective C, but it has been converted to a restricted
version of C++ that will work in an interrupt context: no exceptions and
only single-inheritance. The details of that can be found at:

	http://www.caravan.net/ec2plus/

This is more or less an LKM environment with OO class hierarchies; it's
threaded, pre-emptible, and SMP friendly. Drivers are a thread which reads
from an event queue that contains both user I/O requests and device
interrupts; this is how access to the device (and any device-specific data
structures) is serialized.

They also said "FreeBSD drivers ``just work''" (!!).

[to my annoyance, FreeBSD was mentioned prominently and frequently during
various presentations about MacOS X, but NetBSD got essentially no
acknowledgement of our contribution]

As of WWDC, the "I/O Kit" was not available, but would be up on Apple's web
site "soon."


Random Stuff

There is an internal war going on between the MacOS weenies and the NeXT
weenies. Unfortunately, since Steve Jobs is CEO, and Avie Tevanian is CTO,
the NeXT weenies win the arguments unless the market obviously dictates
otherwise. MacOS X (formerly Rhapsody, NeXT, etc.) is essentially Mach 2.5
underneath, with all the old UNIX warts that will be difficult to deal with
(little support for hot-swap devices or real-time performance in
multi-media or user interface), plus they have to re-educate the NeXT
weenies about the requirements of the desktop/laptoy market that Apple
lives on. It's going to be interesting to watch this from a distance.

MK/Linux is Mach 3.0, but with everyone at Apple being busy with MacOS X,
support for this software is basically gone. I'd say, grab the sources
while they're still available online to use as a reference for those
PowerPC machines we don't yet support (e.g. the older NuBus machines and
non-OF PowerBooks).

Motorola's "AltiVEC" stuff is a full blown (albeit small) vector processing
facility that will be in the G4 PowerPC CPUs late this year, with Apple
shipping machines early next year. Vector Processing is a Single
Instruction, Multiple Data (SIMD) architecture that has been in the
supercomputers from Cray Reesearch from day one; it's part of what makes
them so fast.

Unlike Intel's MMX stuff, AltiVEC has its own vector registers, so you can
fire the IUs, FPUs, and the vector processors simultaneously if you order
the instructions properly, which means that compiler instruction scheduling
is absolutely key to good performance. Supposedly Apple is working with
various third-party compiler folks (hopefully that includes the egcs/gcc
people).

Intially, Apple will be providing a fig-leaf of support in the form of
macros in include files that make the 162 new instructions available as
what appear to be function calls, so that programmers can make explicit use
of the vector processor. Also, there are cache pre-fetch instructions so
that you can attempt to avoid blowing out the L1 data cache and stalling.

If that were not enough, Apple promises that multiprocessor machines are
coming back again soon (presumably the G4 processor has some explicit cache
coherency protocol, because I doubt that Apple will give up on that
separated "back-side" L2 cache). If the NetBSD project didn't have enough
pressure to do MP or SMP support for the Intel and SPARC systems out there,
there will be be additional pressure when the new MP PPC systems appear (of
course, there are older MP PPC systems with the 604 and 604e processors
that we can test on in the mean time).

	For Your Information,

	Erik <fair@clock.org>