can't get enough

Today I checked in my pipe code. It consists of the Pipe() system call, the FSA_PIPE and ACTION_PIPE definitions, the implementation in pipefs.handler, and the changes to shell and the C library to use it. Its nice to have it finished off, but then I got on the bus on the way home and realised I didn’t really know what to work on. I’ve sort of forgotten what I was doing before I started on this stuff, but I’ve also seen a lot of bad code while implementing this stuff and it bothers me to leave it alone.

So, I’ve decided to reimplement pipefs.handler. I can justify it because it will have to be reworked for packets eventually, and it doesn’t actually implement the features and interface of the AmigaOS Queue-Handler which provided the same facilities. It’ll also be an excuse to clean up the horrendous code in pipefs.handler.

The 3.9 SDK has a pretty good description of what the interface is like. Basically, you open some PIPE: object and write stuff to it. The data you write gets buffered in the handler. When something else opens the object and reads from it, it gets everything that was read into the buffer. If the buffer is empty when the last user closes it, the object is destroyed. Otherwise, it hangs around in memory until someone else opens it and reads from it (or you reboot).

Pipes are named and system-wide. PIPE: alone without a “name” (or “channel” as the SDK likes to call it) is still named, and will still do the same thing as a pipe where the name is specified. The name can have CON:-style options to specify buffer size, which of course we can extend in the future.

I should be able to copy a fair chunk of code from fat.handler. The number of packets that need implementing is minimal: FINDINPUT, FINDOUTPUT, FINDUPDATE, READ, WRITE, END, IS_FILESYSTEM and of course PIPE. packet.handler will also need a translation for ACTION_PIPE. In theory this seems simple - I hope it turns out that way.