Subject: |
How to write driver support? |
From: |
[email protected] (Nick Rees) |
Date: |
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]
- Navigate by Date:
- Prev:
Driver HPE 1368A Bob Dalesio
- Next:
Re: WindC++ watson
- Index:
<1994>
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Driver HPE 1368A Bob Dalesio
- Next:
Re: How to write driver support? Bob Dalesio
- Index:
<1994>
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|