TD64 or NSD for new storage drivers?

[olsen]

I've found a million posts on what the available options are and the drama that it caused, but nothing on what users actually want.

For a new storage device driver, which of the two give the best software compatibility and user experience?

TD64 is supported by Phase 5, DKB and GuruROMs, so being compatible to those is a pretty safe bet.

NSD is the OS3.5 and 3.9 standard.

So which one do you want?

My humble suggestion is to support both. The thing is that the functionality common between the different command sets is so large that it's a small effort to increase your chances of producing software which will work with whatever client software there is.

The political dimension of the TD64/NSD schism was a thing to behold, and mourn, since it obscured the fact that both approaches have weaknesses that could have been resolved (or at least mitigated) in a less caustic atmosphere.

For example, testing whether a driver supports TD64/NSD can produce inconclusive results. Because of shoddy device driver implementation practices in the 1980'ies and 1990'ies you also ran a risk to crash the device driver during the TD64/NSD command testing.

Needless to say, none of these issues were ever resolved. Not just because of the caustic atmosphere created, but also because these were really hard problems to resolve in the first place (which in turn was not helped by the caustic atmosphere: brains were more engaged in hurting the other guy than in chipping away at the problem -- I guess because the one thing is tremendous fun for all ages, and the other is work).

In my own client and driver software, I have always supported both TD64 and NSD. It's reasonably simple to do, and I was just absolutely sick of the TD64 vs NSD matter.

Don't let yourself get drawn into the same old sinkhole. It's dark down there, and very hard to get back to the light...

[olsen]

My frustration wasn't with either "standard", it was with the lack of clear direction and information.

I understand; this is one of the side-effects of the discussions, some 15 years ago, which brought forth TD64 and NSD.

I decided to do both once I found out they weren't mutually exclusive.  Some of the misinformation sounded like the command codes conflicted, but that doesn't seem to be the case.

The semantics are identical, but of course the command codes are not.

Just in case: it is generally not sufficient to implement the NSCMD_TD and NSCMD_ETD commands (as in NSCMD_TD_READ64, NSCMD_ETD_READ64, NSCMD_TD_WRITE64, NSCMD_ETD_WRITE64, etc.) without also implementing the NSCMD_DEVICEQUERY command.

If you want to support the NSD command set in the most compatible manner, the NSCMD_DEVICEQUERY command must be supported as well. According to the NSD standard, client software is required to try the NSCMD_DEVICEQUERY command before deciding to give any of the other NSD commands a go. Hence, if you omit support for NSCMD_DEVICEQUERY, you might not produce the maximum compatible solution. Some client applications do not bother with the NSCMD_DEVICEQUERY command and just try their luck with NSCMD_TD_READ64, etc., but you cannot rely upon this behaviour to be present.

And one last thing: please make sure that unknown commands are handled safely (reject them with IOERR_NOCMD), and verify that each IORequest which passes through your device is large enough for the respective command to be performed (e.g. IORequest->io_Message.mn_Length should be at least sizeof(struct IOStdReq) for read/write operations).

[olsen]

Thanks, I appreciate the direct, informative tips.

I will at some point be documenting this as fully as possible.  There is a severe lack of examples for modern or even old device drivers and none that I've seen which have the ability to boot.

I know what you mean. The lack of reference code is an old problem, and it has only grown over the years.

For example, the only reference implementation for a device driver that was ever published by Commodore is written in 68k assembly language, and the only place you can find it is in Appendix B of the "Amiga ROM Kernel Reference Manual, 3rd edition: Devices" (see here: http://wiki.amigaos.net/index.php/Example_Device).

The problems with this implementation are in that hardly anybody can read 68k assembly language code these days and that the code is easily misunderstood as being simplistic and incomplete, while it is in fact a solid example which illustrates how to properly implement a device driver. There is information in this example code which cannot be found anywhere in the other RKM documentation, e.g. proper IOF_QUICK and AbortIO() handling, which is very easy to get wrong.

A couple of years ago I rewrote the same code in plain 'C' (it's not up on the developer Wiki yet), which I believe makes it more accessible. If you want to have a look, please contact me.

Basically if I don't get anywhere with this, I want the information to help the next person who wants to attempt it.  If that's the case then it hasn't been a waste of my time.

Good luck We badly need robust, instructive device driver code. There just isn't enough to go around which one can learn from.

[olsen]

Do there exist any filesystem driver example in C ?

As far as I know this type of sample code is very rare indeed.

If what you're after is an example of how TD64/NSD commands may be used by client code in general, I may have something to share.

A couple of a years ago I wrote a shell command (in 'C', naturally) for the purpose of making image files from my A3000UX hard disk partitions, and uploading them to a local server via TCP. That shell command (called "SendRawDisk") supports TD64/NSD commands, and also includes portable 64 bit integer arithmetic functions for use with compilers which do not support the 'long long int' type (such as SAS/C). It could serve as an example of how this stuff is done in client code. Mind you, it does a bit more than just reading the data off the disk...

You can download the command (with source code) at http://aminet.net/comm/tcp/SendRawDisk.lha