RE:"My driver should create a file with size of 0 blocks and append it. looks like TAR but should be a driver."
So what you really want is a TARACP (similar to what the MTAACP does for File11 tapes), or what the XQP does for disks.
ACPs sit between the driver's FDT and the start i/o routine. They do processing below IPL 3, they operate in process context instead of driver context, so they can do things like call system services.
As far as I know, there isn't any official documentation on writing Ancillary Control Process. Jamie Hanrahan gave several presentations at DECUS (I have the notes from his 1990 Spring DECUS "The What, Why and How of User-Written ACP's"). He and Lee Leahy wrote a book "VMS Advanced Device Driver Techniques" 1988, long out of print . It had had a chapter that was very similar to the notes from his 1990 DECUS presentation. That was for the VAX, but the principles are the same.
Here's an excerpt
---------
Why not use an ACP?
ACP implementation and maintenance requires considerable expertise (same technical level as driver writing, but additional knowledge is required)
ACP's use system routines, data structures, and other kernel-mode interfaces that are not described in the VMS documentation and that must therefore be considered subject to change in future releases of VMS.
Sending a request through an ACP introduces considerable additional overhead.
---------
It is hard for me to understand why having a TARACP would be that beneficial. But you did say this was for learning purposes.
Here are some things to search for with Google if you want some examples.
Glenn Everhart had an ACP virtual disk driver that was submitted to a DECUS tape.
There is a "network tape driver" that I believe is ACP based. It allows a remote tape to be accessed over a DECnet connection, if I am remembering correctly (I never used it).
Just to be clear, LDDRIVER is what I would call a front end driver. It has the same basic parts as a real driver on the user facing side. Its FDT routines accept the requests, modify the LBNs but the start i/o routines hand the request to another driver's routine.
In concept it is somewhat like what using NAT to provide a virtual HTTP server. NAT provides a different view of the same IP address.
As far as your request for a "simple" explanation of i/o in VMS, there was a (2?) hour session given at the last VMS bootcamp by one of the VMS developers.
I agree that making more of that type information publicly available would be a good thing.
But don't expect that after a 2 hour session (or a one week intensive class) you are going to be ready to write a good quality SCSI port driver. Drivers are extremely complex, and there are many pitfalls to avoid.
VMS drivers by design are written to block device interrupts for a minimum amount of time, and then continue on at a lower IPL (fork level) so other device interrupts can interrupt the fork level processing. This is good for reducing the interrupt processing latency, but it is a pain for the device driver writer. Data structures have to be synchronized, etc. etc. It makes writing threaded code look simple.
And to top it off, it has to be correct. If it isn't, you crash.
Jon
it depends
