mounting excitement

We’re in the middle of a heat wave here in Melbourne, as is normal for this time of year. Both Saturday and Sunday were up around 38-40 degrees (celsius), so I couldn’t find much motiviation for anything other than dozing on the couch and complaining.

That said, things continue to move. It seems that my typical code style is to write about five lines, then chase a crash for a few hours/days until finally finding a poor assumption somewhere deep in dos.library. All of DOS assumes (probably reasonably) that the AROS-specific fields in struct DosList were being filled out, so when FATFileSystem decided to add a volume to the system (something filesystems that handle removable media can do), it resulted in a corrupted DOS list and a crash on the next DOS operation. A little detection code in AddDosEntry() was all that was needed.

I think I’ve basically finished the port of FATFileSystem. It had been assuming both that it was running on a big-endian machine and that BCPL strings really were BCPL strings rather than normal C strings that Linux-hosted AROS uses. I rewrote parts of the code to take care of this when running on AROS, and its good now. One more problem removed.

Finally, I’ve got the basic framework for converting IO requests into packets, and converting their results back again. I’m rather proud of the setup, actually. On receiving an IO request, a new packet is created and the request stashed in dp_Arg7, which is rarely (never?) used. The IO request type and parameters are converted and stored in the packet, which is then pushed to the handler on its process message port. Rather than wait for the reply, the request handler now returns, resetting IOF_QUICK to inform the caller that it will have to wait for a response.

A PA_SOFTINT port gets set as the reply port for the packet, which results in a call to another function within packet.handler that takes the result packet, extracts the original IO request from dp_Arg7, populates it with the results from the packet, and replies to the request message so that the caller can receive it.

All of this means that calls to packet handlers are truly asynchronous if the caller wishes them to be, and also means that we only need two context switches for a packet round-trip. This setup makes it exactly like the traditional AmigaOS environment for packet handlers, and means that packet-based filesystems shouldn’t perform any worse on AROS than they do on other systems.

So far I’ve only implemented a few filesystem requests:

• FSA_IS_FILESYSTEM (converts to ACTION_IS_FILESYSTEM)
• FSA_OPEN (converts to ACTION_LOCATE_OBJECT)
• FSA_CLOSE (converts to ACTION_FREE_LOCK or ACTION_END)
• FSA_DISK_INFO (converts to ACTION_DISK_INFO)

These are enough to do this:

The “filesystem action type unknown” is in response to an attempt to perform FSA_EXAMINE, which I haven’t implemented yet. That should happen within the next couple of hours on my bus trip home.