Experimental Physics and
Industrial Control System

[email protected] (Nick Rees) · Thu, 17 Nov 94 23:48:24 HST

I am embarking on my first set of driver support routines and I am casting
around for standard ways to do things. Looking through a number of pieces of
code reveals:

1. There are really no standard ways of doing things - apart from the driver
   support functions which don't actually contain an I/O function.
2. Many drivers appear to have much in common with VxWorks device drivers (at
   least to me, who also has never written a VxWorks device driver).

Is there any reason why Epics driver support code should not also be a VxWorks
I/O device driver? Would this not be a sensible way to write them? Are
there any impossible pitfalls which is why people don't use them.

Thats my question, and those who aren't interested stop here (there may
be waffle ahead!). However I have thought about it a bit so those who are
interested (or wish to procrastinate) may wish to comment on some
background musings...

I must admit I owe a lot to DESY and their CDI interface. For those who
don't know, this is a common driver interface which looks very similar to
the VMS qio/qiow interface (Gabor got to know this interface well in a
previous life). The qio/qiow interface is the VMS way of interfacing to
its drivers, and is roughly equivalent to the three Unix calls open, close and
ioctl all rolled into one.

I came away from DESY thinking the idea of a common driver interface is
great, and what Gabor has produced is a fine implementation, but I much
prefer the Unix style of interfacing to devices. What I don't like is
that the qio call is fairly complicated (since it serves many functions)
and I find it a pain to use for the simple reads and writes I mostly
perform.

Having put it this way the next step should be fairly obvious, but it took
me 3 months to think of it. Why not adopt the VxWorks device driver
interface as a common driver interface (with apologies to Gabor for using
the same name at the moment). I don't want this to be seen as
antagonistic to the DESY idea, but I see it as a plausible suggestion for
novices like me to use the VxWorks device driver model as a guide to
writing Epics driver support software.

Having had the idea I spent a fair bit of today looking at the
implications of all this. Some points:

1. What do I mean by this?

   At a bottom line, it is introducing the VxWorks I/O driver support
   routines as a suggested set additional to the current Epics driver support
   routines. The current Epics set of driver support routines appears to be
   just report and init. The VxWorks ones are create (which is
   probably equivalent to the current init), remove, open, close,
   read, write, and ioctl. The remove and close may be NULL a
   lot of the time, as will read (or write) for a input (or output) only
   piece of hardware.

   In addition to this there will be a style of writing drivers so that
   they work with the VxWorks file system.

   By the way, I am not saying you have to do it this way. But if enough 
   people thought it a good idea, it may become a de facto standard.

2. What about Epics dependencies?

   If you decide to write standard VxWorks drivers do you want to keep
   Epics dependencies? To remove them completely you could have an
   external function entry table with all the Epics function addresses in
   it that could be initialised by an ioctl. If you didn't initialize it
   then the driver would still work by not make the Epics calls (it would
   have to check the entry table to ensure the routine were not NULL before
   calling ther routines.

3. What would be a reasonable standard way of getting the device type and link
   description down into the driver?

   There are two alternatives: Either encode it in the VxWorks device
   and file name or use an ioctl call to set it (with the initial value being
   something like card 0, slot 0 - or the equivalent for other types of
   link). A compromise may be to have a different VxWorks device
   for every different DTYP, and get device support to pass the link 
   information down via an ioctl.

4. What is the efficiency hit?

   Don't know, does anyone have any ideas? Reading the VxWorks docs they
   imply little more than an additional call overhead (to resolve the
   file number into a device call - it is just an array lookup of a
   function address). If you didn't want this you could call the VxWorks
   driver support routines directly from device support, bypassing the
   I/O system.

5. Is it more difficult?

   Reading the VxWorks docs it appears to me it isn't, it is just a
   slightly different way of doing things. However, this way is a
   standard, documented way, so there is the hope that it is clearer
   what is going on.

6. How different is it to what is done now?

   I don't think it is a lot different from many drivers. I looked at
   a few sample ones, and they typically have two main external routines
   - a read (or write), and/or something called xxxx_driver, which often
   looks very similar to ioctl.

7. What support structure would we need?

   By this I mean prewritten code or standards to make life easier. An
   obvious thing would be to define a couple of standard ioctl calls that
   drivers may support. I have mentioned a few already, but another
   obvious one would be to define a callback for asynchronous read/write
   operations. 

   Also a trivial code template to start working with is always helpful.

Well, what do people think? I am tempted to write my first driver this
way just to find out whether it works or not.  If anyone can think of any
show stoppers, let me know.

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System