The latest news is I haven't played with this much in the last month.
My belief is I can't get writes reliable with the current approach to things. Reads are totally reasonable, but I've been struggling to get the writes reliable and the more I work on it, the more problems I become aware of.
I currently need to focus on packaging up a read-only release with some of the newer improvements I've been working on.
As for testing with long term connections, the driver creates a new connection for each operation. So each read/write translates to a PUT/GET request on its own connection. It is not using HTTP/1.1 keepalive. So long term idleness isn't really an issue, although efficiency is something else entirely.
There's no particular reason this couldn't be modified to work with a diskcopy image. I'm not familiar with the various disk copy image types, but from what little I do know, it seems reasonable.
The big topic on everyone's mind seems to be netbooting. Believe me, this is at the front of my thoughts.
I don't think this would make a good basis for netbooting. But don't despair, there are plans.
Some background (this might be duplicated elsewhere on the forum, but I'll wing it from memory here again), feel free to skip ahead:
It is my belief Declaration ROMs are a good way to add code/drivers in ROM for booting purposes, even the System ROM. All system ROMs from the Mac II up have a "Slot 0" declaration ROM. Using dougg3's ROM SIMM, adding code to the Slot0 DeclROM should be a relatively easy, non-destructive way to add code/drivers (compared to overwriting the .Sony floppy driver like I was doing with the ROMDisk driver).
DeclROMs are basically a directory structure, each entry being a "resource ID" that can contain multiple attributes. All DeclROMs have a resource that provides a description of the board (name, general type such as NIC/Video/etc). It can have supplemental resources, the declroms I've peeked at typically have one resource for each supported resolution/color depth setting for video cards, and SCSI cards have one resource for each SCSI ID in the chain.
When booting from a slot (nubus, pseudoslot, whatever), the PRAM stores both the slot ID and the resource ID within the declrom. So you don't just boot from a slot, you boot from slot+resource. In the case of a SCSI card, if there is one resource per SCSI ID, that's how you know which of the potentially multiple SCSI IDs attached to the card to boot from.
Additionally, when booting, the Start Manager/Slot Manager doesn't just load the device driver from that resource within the declrom at the designated slot, and try to boot from it. It actually loads and runs a different set of code in the resource. Typically, that code loads a driver from its own resource id, and begins the boot process, but really can do anything it wants. Including looking at currently pressed keys to decide whether it wants to be bootable.
So, although this HTTP Disk driver could easily be loaded in this manner, it uses MacTCP, which isn't in ROM. Adding it to ROM too is a problem for multiple reasons: it finds its self inside the System Folder and loads resources from its self in order to do DNS resolution, it looks on disk for network configuration information, and the real kicker ends up being ethernet drivers.
Most ethernet cards do not have drivers for themselves in their declrom. Ethernet drivers aren't DRVR driver resources at all. They're 'enet' resources. There is a .ENET driver, but that's not the same thing, that's more of a generic interface to the various 'enet' resources.
Ultimately, for a bootable solution I'm thinking the approach taken by others back in the day is the way to go: Implement your own 8390 ethernet driver, and a minimal IP stack in a declrom, and then fetch a disk image (protocol is a mere implementation detail here, supposedly ye olde solutions could fetch an image from tftp or AppleShare), and boot it as a RAM disk image.
As for how to find the image to boot from, this is a problem that has been solved over and over again, all differently. People have used more solutions to that problem than I care to contemplate. That part isn't something I'm terribly worried about, and at the moment would lean towards just using existing DHCP options, falling back on PXE-like default server/file naming conventions.
Plus, with a custom IP stack, making this HTTP disk driver writable would be much easier. It's just a Simple Matter Of Programming, right?
My belief is I can't get writes reliable with the current approach to things. Reads are totally reasonable, but I've been struggling to get the writes reliable and the more I work on it, the more problems I become aware of.
I currently need to focus on packaging up a read-only release with some of the newer improvements I've been working on.
As for testing with long term connections, the driver creates a new connection for each operation. So each read/write translates to a PUT/GET request on its own connection. It is not using HTTP/1.1 keepalive. So long term idleness isn't really an issue, although efficiency is something else entirely.
There's no particular reason this couldn't be modified to work with a diskcopy image. I'm not familiar with the various disk copy image types, but from what little I do know, it seems reasonable.
The big topic on everyone's mind seems to be netbooting. Believe me, this is at the front of my thoughts.
I don't think this would make a good basis for netbooting. But don't despair, there are plans.
Some background (this might be duplicated elsewhere on the forum, but I'll wing it from memory here again), feel free to skip ahead:
It is my belief Declaration ROMs are a good way to add code/drivers in ROM for booting purposes, even the System ROM. All system ROMs from the Mac II up have a "Slot 0" declaration ROM. Using dougg3's ROM SIMM, adding code to the Slot0 DeclROM should be a relatively easy, non-destructive way to add code/drivers (compared to overwriting the .Sony floppy driver like I was doing with the ROMDisk driver).
DeclROMs are basically a directory structure, each entry being a "resource ID" that can contain multiple attributes. All DeclROMs have a resource that provides a description of the board (name, general type such as NIC/Video/etc). It can have supplemental resources, the declroms I've peeked at typically have one resource for each supported resolution/color depth setting for video cards, and SCSI cards have one resource for each SCSI ID in the chain.
When booting from a slot (nubus, pseudoslot, whatever), the PRAM stores both the slot ID and the resource ID within the declrom. So you don't just boot from a slot, you boot from slot+resource. In the case of a SCSI card, if there is one resource per SCSI ID, that's how you know which of the potentially multiple SCSI IDs attached to the card to boot from.
Additionally, when booting, the Start Manager/Slot Manager doesn't just load the device driver from that resource within the declrom at the designated slot, and try to boot from it. It actually loads and runs a different set of code in the resource. Typically, that code loads a driver from its own resource id, and begins the boot process, but really can do anything it wants. Including looking at currently pressed keys to decide whether it wants to be bootable.
So, although this HTTP Disk driver could easily be loaded in this manner, it uses MacTCP, which isn't in ROM. Adding it to ROM too is a problem for multiple reasons: it finds its self inside the System Folder and loads resources from its self in order to do DNS resolution, it looks on disk for network configuration information, and the real kicker ends up being ethernet drivers.
Most ethernet cards do not have drivers for themselves in their declrom. Ethernet drivers aren't DRVR driver resources at all. They're 'enet' resources. There is a .ENET driver, but that's not the same thing, that's more of a generic interface to the various 'enet' resources.
Ultimately, for a bootable solution I'm thinking the approach taken by others back in the day is the way to go: Implement your own 8390 ethernet driver, and a minimal IP stack in a declrom, and then fetch a disk image (protocol is a mere implementation detail here, supposedly ye olde solutions could fetch an image from tftp or AppleShare), and boot it as a RAM disk image.
As for how to find the image to boot from, this is a problem that has been solved over and over again, all differently. People have used more solutions to that problem than I care to contemplate. That part isn't something I'm terribly worried about, and at the moment would lean towards just using existing DHCP options, falling back on PXE-like default server/file naming conventions.
Plus, with a custom IP stack, making this HTTP disk driver writable would be much easier. It's just a Simple Matter Of Programming, right?