cold fusion explosion

I mentioned in a comment that FUSE-based filesystems could be fairly easy to port since they’re not in the kernel and therefore shouldn’t have tight dependencies on the kernel VM subsystem. I’ve had a chance today to investigate this a little further.

FUSE-based filesystems run as standalone processes. In their setup they pass a single object to the FUSE library that contains pointers to handler functions for each filesystem operation. They then call a mainloop function and let the library dispatch filesystem calls from the kernel appropriately.

To get this on AROS, we’d just need to implement the FUSE library interface. Like the packet stuff, this would be done via a special fuse.handler that would handle conversion from IOFS requests to FUSE calls and back again. It’d probably be a little more complex than packet.handler as FUSE is designed for POSIX operations and semantics, so there’d likely be multiple FUSE calls for certain operations. I don’t think that would have to be a huge problem though.

The Type option that I added to the Mountlist would then get the handlers online, eg:

FileSystem = ntfs.handler
Type = FUSE

Many different filesystems are available using FUSE. Most of them aren’t particularly useful other than in very specific application domains, but a fuse.handler would immediately give us support for NTFS and ZFS. Those alone are reason enough to do it, so I’ll start looking into it.

Packets are basically done anyway. There’s a few issues to sort out and a heap of testing, but without packet handlers available I can’t do much. I’ll probably mostly backburner packets for a little while (maybe a week or two) while I chase Marek, and work on fuse.handler. It’ll help the packet work anyway, as it’ll give a second implementation of the filesystem proxy model. This should be fun :)