NSD Future - Revision history

Steven Solie: /* Revision */

2013-04-11T19:05:44Z

Revision

← Older revision		Revision as of 19:05, 11 April 2013
Line 1:		Line 1:
	= Revision =		= Revision =

	Version 1.2 (~~1996~~-10-06)		Version 1.3 (2013-04-11)

	= Future Directions =		= Future Directions =

Steven Solie: /* Future Directions */

2013-04-11T19:05:25Z

Future Directions

← Older revision		Revision as of 19:05, 11 April 2013
Line 13:		Line 13:
	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.		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 at in ~~the~~ ~~RKM~~.		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\|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.		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.

	This document needs to be presented in a more readable form and possibly in hypertext form. It should also continue to be available in plain text, though. texinfo may be a good and portable choice with minimum environment needs, as long as illustrations are not needed.

Steven Solie: Created page with "= Revision = Version 1.2 (1996-10-06) = Future Directions = What are the future directions for NSD? Currently the items mentioned in the following paragraphs are under cons..."

2013-04-11T16:49:58Z

Created page with "= Revision = Version 1.2 (1996-10-06) = Future Directions = What are the future directions for NSD? Currently the items mentioned in the following paragraphs are under cons..."

New page

= Revision =

Version 1.2 (1996-10-06)

= 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 at in the RKM.

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.

This document needs to be presented in a more readable form and possibly in hypertext form. It should also continue to be available in plain text, though. texinfo may be a good and portable choice with minimum environment needs, as long as illustrations are not needed.