Exec style Devices

[bloodline]

Ok, some more, perhaps stupid questions.

When you open a device, you establish a “communication channel” with that device via a single IORequest messsage. So you can use this to submit commands to the device and receive responses (if required), via this IORequest.

What formal process is there for streaming commands to a device? Say that I don’t care about any response, I just want to send an arbitrary number of command messages to the device, and it is up to the device to handle them (or not), my task doesn’t care, it just wants to send several command messages and then move on (maybe terminate, or whatever), relying on the device’s message port queue to ensure the device received them.

[Thomas Richter]

Originally Posted by bloodline

When you open a device, you establish a “communication channel” with that device via a single IORequest messsage. So you can use this to submit commands to the device and receive responses (if required), via this IORequest.

What formal process is there for streaming commands to a device?

You allocate as many IORequests as you need, open the device with one of them, and then memcpy the IORequest to all other allocated requests. Then, you SendIO() the requests in any order you seem fit, and the device handles them "first come, first served".


Typically, you would allocate a limited number of requests and SendIO() them, when you run out of them, you wait for the signal of the reply port, and then CheckIO() which of the requests became ready. On such a request, you WaitIO() to dequeue it from the port - it is then ready for recycling, and can be SendIO()'d again.


The FFS (and many other file systems) create IORequests whose io_Node.ln_Name points to a struct DosPacket of type ACTION_READ_RETURN or ACTION_WRITE_RETURN. This way, when the packet is replied by the device, the FFS (or other handler) receive a "pseudo packet" of the particular type (ACTION_READ_RETURN) and then continue with the activity.


Actually, what FFS does is that it creates a co-routine for every file handle, and on ACTION_READ_RETURN this co-routine continues to operate. As of 3.1.4, CrossDos and the CDFileSystem work the same - this way, FFS can continue to serve requests while the device (e.g. the trackdisk.device) is busy.

[bloodline]

Originally Posted by Thomas Richter

You allocate as many IORequests as you need, open the device with one of them, and then memcpy the IORequest to all other allocated requests. Then, you SendIO() the requests in any order you seem fit, and the device handles them "first come, first served".

Excellent that’s exactly the behaviour I was expecting. I did wonder if I could just make copies of the initial IORequest and send them as needed, but that felt a little “clumsy”/kludgy?

Typically, you would allocate a limited number of requests and SendIO() them, when you run out of them, you wait for the signal of the reply port, and then CheckIO() which of the requests became ready. On such a request, you WaitIO() to dequeue it from the port - it is then ready for recycling, and can be SendIO()'d again.

This feels like a very efficient way to do the IO!
As you are essentially batching all your requests.

The FFS (and many other file systems) create IORequests whose io_Node.ln_Name points to a struct DosPacket of type ACTION_READ_RETURN or ACTION_WRITE_RETURN. This way, when the packet is replied by the device, the FFS (or other handler) receive a "pseudo packet" of the particular type (ACTION_READ_RETURN) and then continue with the activity.

That’s a rather clever little hack! Though it’s a shame it couldn’t be implemented in a cleaner way.

Actually, what FFS does is that it creates a co-routine for every file handle, and on ACTION_READ_RETURN this co-routine continues to operate. As of 3.1.4, CrossDos and the CDFileSystem work the same - this way, FFS can continue to serve requests while the device (e.g. the trackdisk.device) is busy.

This was actually what started me wondering about queuing device IORequeats, there is often no need to block, just let the device handle the messages when it gets to them!

Many thanks for your insight again!

[Thomas Richter]

Originally Posted by bloodline

Excellent that’s exactly the behaviour I was expecting. I did wonder if I could just make copies of the initial IORequest and send them as needed, but that felt a little “clumsy”/kludgy?

You can, but you need to do after opening the device, so the order is important. Actually, what is really needed is to initiialize io->io_Device and io->io_Unit, so copying that over is also sufficient. A memcpy() is just simpler and also does the job.

Originally Posted by bloodline

That’s a rather clever little hack! Though it’s a shame it couldn’t be implemented in a cleaner way.

A cleaner way would be to use two separate ports, one for the incoming packets the handler is supposed to answer, and another port for the IORequests coming back from the device. So it is possible, it is just not necessary.

Originally Posted by bloodline

This was actually what started me wondering about queuing device IORequeats, there is often no need to block, just let the device handle the messages when it gets to them!

Typically not, but there is a catch if two incoming requests attempt to alter the same block or the same state of the file system. The FFS has a very complex co-routine system plus "wait queues" for the co-routines to avoid the trouble. The CDFileSystem and CrossDos is multithreaded as far as data transfer is concerned, but the administration logic is single-threaded - unlike the FFS.


The FFS is actually smarter than one thinks - at least as far as the asynchronous I/O handling is the case. The adminsitration disk structure is from days in the past.