Conference vaxaxp::vmsnotes

    You will need the driver-porting manual (see the OpenVMS Alpha V7.1
    documentation set for the latest driver manuals), and a copy of the
    OpenVMS source listings CD-ROM.  You might also be interested in
    the I/O User's Guide (for the TTDRIVER information), and in the
    Internals and Data Structures Manual.

    The IRP structure has seen some changes.  (The documentation set
    contains the documented portion of the IRP...)

    All of these calls underwent changes to their calling interfaces, or
    were removed.  (In the cases I recognize here, it was the former.)

    Be aware that you will also be porting from VAX to Alpha Macro32, or
    from VAX Macro32 to Alpha C.  (I'd recommend the latter of the two,
    when  possible.)

    Thanks you cery much for your quickly answer.
    
    The real question is:
    
    Can I buid a Class Driver on TT_Driver using OpenVMS Alpha V.7.1 ?
    
    (I forget to say that the TT_Driver uses the LAT_Driver)
    
    Again:
    
    Can I order the OpenVMS source listing CD-ROM ?
    
    Thank you again and Ciao. Filippo.

    How often, and what sorts of messages, are being passed to the
    OpenVMS VAX terminal driver ALTSTART in the current scheme?
    
:    Can I buid a Class Driver on TT_Driver using OpenVMS Alpha V.7.1 ?

    There is no formal support for writing a class driver above an existing
    class driver -- TTDRIVER is a class driver.   (This can certainly be
    done given enough time and resources, and given source access, but it
    would be "interesting" to maintain and to enhance this "super-class"
    driver.)

    There is an ability to layer a port driver underneath the TTDRIVER
    class driver on both VAX and Alpha.  (For information on this on VAX,
    see the Device Driver Manuals.  For Alpha, I suspect you'll end up
    looking at the source listings for the details -- I don't have the
    latest V7.1 driver documentation handy to check this, but this
    interface is not overtly documented in the OpenVMS Alpha manuals
    through V7.0.)

    However, it would appear you want to pass requests directly to
    the terminal driver ALTSTART interface.  (This is not documented.
    This was never documented on OpenVMS VAX, either.)  This is not
    normally considered a class driver...  You will need the source
    listings to do this.  You will also have a driver that is tied
    to an undocumented interface -- I would look for alternatives.

    As an alternative, depending on what sort of messages you are
    trying to send and how often you are trying to send them, you
    may be able to send requests via breakthrough messages.  (This
    is one of the few ways that a device driver can "normally" access
    a terminal from high IPL.)  Infrequent requests can be sent via
    an (undocumented interfaces) ACP, using the (documented) user-mode
    interfaces to the terminal driver.
    
:    (I forget to say that the TT_Driver uses the LAT_Driver)

    TTDRIVER uses a number of port drivers, LTDRIVER is one.  (There are
    port drivers available for all supported serial-line controllers.)
    
:    Can I order the OpenVMS source listing CD-ROM ?

     Yes.  Please see notes 8.* and 9.* for this information.
 

    You can layer a pseudo-driver on top of a class driver.  This can
    be a good fit if you primary function is to build "special" IRP's.
    
    Rob

    Sorry for my request,
    
    but What is the ALTSTART interface ?
    
    the driver I have to migrate uses the  EXE$INSQIOC to submit a
    TT_driver IRP packet to TT_driver itself.
    
    Thanks again for the answer.
    
    Ciao. Filippo.

   What problem are you trying to solve?   What is the kernel-mode
   code (device driver or otherwise) -- the code that you are trying
   to hook directly to the terminal driver -- doing?
    
:    but What is the ALTSTART interface ?

   You definitely need access to the device driver manuals, as
   "ALTSTART" is an documented interface that is quite commonly
   used by many OpenVMS device drivers.  (And I don't intend this
   to sound rude.) 

   A driver's STARTIO interface is a synchronous interface -- I/O
   request packets (IRPs) are queued if the device is busy.  The
   ALTSTART interface is asynchronous, and requests are processed
   as they are received by the driver.

:    the driver I have to migrate uses the  EXE$INSQIOC to submit a
:    TT_driver IRP packet to TT_driver itself.

   Device drivers typically have a STARTIO and an ALTSTART interface,
   and the technique you are considering here involves kernel-mode
   code constructing an IRP and passing it to the device driver
   STARTIO or ALTSTART interface.  EXE$INSIOQ is the OpenVMS VAX
   routine that does this, and -- due to the kernel-mode calling
   interface changes made for OpenVMS Alpha high-level-language
   drivers -- EXE_STD$INSIOQ is the OpenVMS Alpha equivilent.

   ALTSTART interfaces are typically considered to be entirely internal
   to the driver (or set of drivers) and are undocumented; those drivers
   that expect to be called from other (related or unrelated) kernel-mode
   code often implement a seperate calling interface in addition to (or
   to supplement) an ALTSTART interface.

   A class driver usually as the code to call a port driver (most
   often via a privately-, internally- or externally-documented
   interface other than ALTSTART), and a port driver is usually
   coded to be called via a non-ALTSTART interface. 

    
    	I have stayed out of this so far.  The altstart path in TTDRIVER is
    used for write requests only.  If you queue reads to this you will not
    like what happens.  The startio path is used for all other requests and
    for writes if the driver is set to halfduplex.
    
    	We really need to understand what the driver you are trying to port
    was/is supposed to accomplish.  Then someone here may be able to
    suggest a cleaner way to solve the problem.  I believe that the code
    can be ported but you need to get a copy of the Alpha Device driver
    writers book.  You also need a pretty fair understanding of how I/O
    works.  You will now have code that compules and links and will even
    load.  But there is just enough difference that a simple conversion of
    the code and replacement of the old routines with new ones to insure
    that it probably will not work.
    
    
    Forrest
    OpenVMS terminal driver historian

Hi,
        about my note number 468 the customer environment is changed.

        The Class driver (on TT_driver) has to migrate, but it must be written
in "C" language.

        I understand it is possible (with the source listing and enough time)
to port the driver, but I have another question:

        If the target OVMS version is the Alpha OVMS V.6.2, does the support
to write a driver in "C" language exist in this version ?

        Thanks in advance and Ciao. Filippo.

        P.S. If someone can help me, I can send to him the class driver source
listing.

:        If the target OVMS version is the Alpha OVMS V.6.2, does the support
:to write a driver in "C" language exist in this version ?

   OpenVMS Alpha V6.1 and later support device drivers written in C.

    Where can I find the documentation about "How to write a device druver
    using "C" language in OVMS V.6.2 (or V.6.1)" ?
    
    Thanks in advance and Ciao. Filippo

:    Where can I find the documentation about "How to write a device druver
:    using "C" language in OVMS V.6.2 (or V.6.1)" ?

   See note 8.* and 9.* for pointers to the documentation areas.

    
    	Send me the listings I will look at them if I have time this week.
    
    
    Forrest
    OpenVMS Terminal driver person