Daynaport SCSI and persistent mounts - I have a workaround

[snhirsch]

Based on a lot of web research and discussion on Mac fora, I've concluded that the Daynaport SCSI device is not able to provide support for remount after restart on System 7.x. (tried on 7.1, 7.3.5, 7.5.5, 7.6.1). Whatever portion of the operating system that registers the machine on the Appletalk network expects networking to be up and running very early in the boot process. The .ENET0 device becomes available at the end of initialization, which is too late. At this point you can remount manually - every time. None of the suggestions I received (fiddling with ResEdit, reordering drivers, etc) worked.

Today I fired up an OS 8.1 image that had been patched for the SE/30 and installed the Dayna SCSI driver. Lo and behold, remount worked! After a lot of binary searching through the extension manager settings I was able to determine that 'Modem Manager' is what does the initial registration. Hope this helps others struggling with the issue.

There may be a way to get it working on earlier MacOS versions, but I think the solution will require more low-level hacking knowledge than I have.

[aperezbios]

@snhirsch good to know! It seems like the easiest thing to try would be to attempt to load the Modem Manager extension from 8.1 under 7.5.3/.5/7.5.6 and see if that changes the behavior at at all. Thanks for investigating this.

[snhirsch]

I tried copying the 'Modem Manager' control panel to the 7.x extensions folder. No joy. Then I additionally copied the Daynaport driver extension over (seems particular to the 8.1 install). Still no joy.

I found this on one of the forums as part of a slightly different conversation about networking:

"Crude and bothersome" is a fairly apt description of the way a lot of
things are in the Classic Mac OS network stack. It might work pretty
well externally, but having spent a lot of time recently writing my
own Ethernet driver, the internals are inelegant to say the least. The
unfortunate fact is that there's a reason for some network drivers
(such as the DaynaPort SCSI drivers) having to live in the System
file, but it's a pretty frustrating one, and explaining it requires a
bit of background on the ugliness under the hood. Beware, wall of text
incoming.

Basically, there are two more-or-less independent classes of Ethernet
driver - the .ENET driver stub for Ethernet devices that use the Slot
Manager (e.g. NuBus or 030 PDS), and the .ENET0 driver for devices
that exist outside of the Slot Manager's worldview (e.g. SCSI or 68000
PDS). Software is expected to just look for devices under both
drivers, which is why you'll sometimes see a network device listed as
"Ethernet (Alternate)" - some versions of the Network control panel
use this to indicate a device using the .ENET0 driver.

The .ENET driver stub is by far the more 'civilised' of the two - it
exists on all systems with network software installed, and when
loaded, searches for an 'enet' resource whose ID matches the Board ID
in the Ethernet device's declaration ROM, and loads the actual driver
from there. In later versions (starting with Network Software
Installer 1.4 I think?) it even looks for drivers in Extensions of
type 'comd', doing exactly what you suggested, but because it is keyed
off of the declaration ROM Board ID, this only works for Ethernet
devices that the Slot Manager knows about.

For Ethernet devices that aren't supported by the Slot Manager, things
are much more primitive. A driver for these devices must install
itself as .ENET0, with no help from the operating system. And here's
the sticking point: for AppleTalk to come up correctly, the Ethernet
driver must already be present in the driver table before AppleTalk
starts, which is very early in the boot process, before INITs get
run. For Slot Manager devices, that's fine, the .ENET driver stub is
always there, and when AppleTalk opens it, it looks up the appropriate
driver and passes control to it. But for non-Slot Manager devices, the
only practical way to make their .ENET0 driver available so early in
boot, is to install it into the System file's 'DRVR' resources, so
that it is always present in the driver table. Another related
limitation is that while a system can happily have any number of
drivers installed for Slot Manager cards, and just pick the right one
based on the hardware that is installed, only one .ENET0 driver can be
installed in a system at a time, as far as I can tell. Not a huge
problem for most people, but it led to a bit of confusion when
bringing up the driver for my ethernet card on my SE.

I know that there *are* ways to hook Extensions earlier into the boot
process (e.g. by abusing language-system 'scri' extensions), and it
may be possible to use these hooks to load a .ENET0 driver into the
driver table before AppleTalk starts up, but as far as I'm aware these
hooks were only ever intended for Apple's own use, and as such are
poorly-documented and not supported on all systems. It's something
I've been meaning to investigate for my own drivers, but I suspect
that there's a reason that Apple and other vendors didn't do it that
way.

Hope this is helpful.