Hi all,

now that my questions have resulted in such a commotion, I've started
looking deeper into what Apple says about the ADB. The sources I have
scanned include

[1]     Inside Macintosh V-361f.: The Apple Desktop Bus
[2]     New Inside Macintosh/Devices: The ADB Manager
[3]     TechNote #206: Space Aliens Ate My Mouse
[4]     New Technical Notes HW 505: Apple Desktop Bus Q&As
[5]     c't 11/1994 p.230f.:Universelles Interface f=FCr den Apple Desktop-B=
us


=46irst a look at hardware issues:

In all I've read, I have never seen a warning about hot plugging the ADB
with respect to potential hardware damage. (Anything about that in Apple's
hardware related books? Haven't got any here.) Do you switch off your
walkman before you unplug the earphones? Does it damage your telephone if
you unplug it? There goes a saying that technical devices should be as
simple as a toaster or at least behave like it; I always felt that
Macintoshes somehow belong to the second category. And from all my
experiences with computer hardware (which includes wiring of five 'Europa'
size boards for a Z80 machine), I expect the ADB to be no more subject to
damage than e.g. a serial port. Excessive static discharge is dangerous,
but in general LSIs can be amazingly hard to kill once they are soldered
in...


The warnings I've read are related to software issues:

[1] warns that connecting a device to a running Mac may reset all devices
on the bus without informing the system, thus bringing some devices out of
sync with their driver.
I have shown that at least for a vanilla configuration ( one kbd + one
mouse), MacOS (and even MacsBug!) can deal with this.

Scott Reynolds <scottr@edsi.org> pointed out that, given several devices of
the same type on the ADB, a reset may revert them to their default
addresses and so make them indistinguishable to the system.
Again, this is not relevant for a vanilla configuration - no ID clashes
here, no ID reassignments.


What it boils down to:

As it is, if you boot MacBSD on internal video and have no keyboard
installed, it hangs indefinitely in the ADB init code - no error handling,
nothing. You could have getty(8) enabled on the serial ports, you could
have ethernet connectivity, but the ADB code leaves you with no chance to
get there.

There is a similar issue that I recently discussed with Bill Studenmund: If
you boot to serial console and switch off the terminal/the computer used as
console, the serial console deliberately panics. This machine could be a
file server, an internet router, an SQL database server, needing no
console, but anyway, it panics.
DON'T PANIC, one might say here, in large, friendly letters...

IMHO, in both cases MacBSD chooses a too conservative approach. Absence of
a keyboard is no reason at all for freezing the machine; a cleaner way to
handle the situation would be to assume a _default_configuration_ (e.g. ID
2: kbd, ID 3: mouse). If anything else is plugged in and you find you
cannot deal with it there is still time to syslog() and lock the ADB. But
even then you could login via serial line or network, su(1) to root and
clean up -- no need to lock up or panic.

My proposal:

When MacBSD boots to internal video and finds _no_ ADB devices, it falls
back to a default configuration - 1 vanilla keyboard, 1 vanilla mouse - and
resumes booting. You can then decide if you want to take a risk and plug in
an ADB kbd or if you rather log in on a serial line or via network.




	hauke

---
"It's never straight up and down"     (DEVO)