NSD Future

Revision

Version 1.3 (2013-04-11)

Future Directions

What are the future directions for NSD? Currently the items mentioned in the following paragraphs are under consideration. They are phrased as suggestions to think about. Obviously, thoughtful comments are very welcome.

It may be useful to add NSDEVTYPE_NARRATOR for the future to bring back a narrator eventually. A future narrator may be a completely different beast for input and output than the one that used to be part of the OS, which means that the meaning of a device type like this needs a lot more thought in general. So if someone has an intention to create a narrator like NSD device, please get in contact with us.

It has been suggested that the query result should contain the size of the expected I/O request for general use. This would make it possible to extend the functionality of an existing device type by optionally extending its IORequest in agreed upon and standardized ways without having to introduce a new type specifier. This is tricky, though, as a single device type may have multiple valid sizes depending on the command used, like the original trackdisk.device. Maybe the maximum supported size should be set here to give an indication of the maximum available request feature size. Maybe a table of possible sizes, indicating different features should be returned.

SANA devices pass in necessary configuration data on OpenDevice(). This is not really such a great idea within the NSD context. A general NSD command to pass in configuration data for any device type may be a very good and very important thing to keep OpenDevice() close to its original meaning as hinted in Exec Device I/O.

There should be comments on how I/O requests are correctly duplicated. Official documentation on this has always been sketchy at best, and the fact that for any device type basically only the io_Device and io_Unit IORequest need to be duplicated, except for device specific data in an extended request structure, has not been really defined well.