Today I checked in my pipe code. It consists of the
Pipe() system call, the
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
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:
IS_FILESYSTEM and of course
packet.handler will also need a translation for
ACTION_PIPE. In theory this seems simple - I hope it turns out that way.