Experimental Physics and
Industrial Control System

Timo Korhonen <[email protected]> · Wed, 01 Sep 1999 10:13:41 +0200

Benjamin Franksen wrote:

> Timo Korhonen wrote:
> >
> [...]
> > I also had a similar problem with GPIB support (we are using the HPE2050 LAN
> > gateway support
> > from Benjamin Franksen at BESSY) when porting device support modules.  When I
> > removed the "static"
> > keyword in devGpib.h :
> > /*static*/ struct devGpibParmBlock devSupParms;
> > the drivers started to work. When declared static, the data that was supposed
> > to be in the structure was
> > not correctly passed from the init routine to the records.
> >
> > These changes seemed to work, but does somebody have an explanation why?
>
> This is a compiler bug of gcc in the version that is shipped with
> VxWorks 5.3.1. See the thread starting with
> http://www.bessy.de/MailLists/b-tech-talk.1998/frm00696.html (in which I
> stated wrongly that it would be ok to change static to extern, Marty
> convinced me otherwise).
>

I tested the example that was in Marty's posting and it seems that our
cross-compiler
(gcc 2.8.1) does not have that bug.  So the explanation (in our case) must be
elsewhere.

> > On the other hand, this seems sort of logical because static variables are
> > valid only within a program
> > unit (according to my textbook), but why does this then work with a 68k cpu?
>
> Well, the static variable 'devSupParms' never used _directly_ by other
> modules, so it can and in principle should be private (ie 'static'). It
> furthermore _must_ be private at least if you have more than one GPIB
> device support, lest you get a name clash.

Here I was pointing more to the OMS58 driver problem. Sorry for mixing two
different things, but I thought the origin probably is the same and I was looking
for
enlightment on that issue. And I did get a reply ;-)

The name clash I had (painfully) noticed, with the two GPIB devices I have on my
desk.
But I had missed the proposed fixes, although I had seen those postings (on my
own,
I arrived at individually naming the devSupParms individually per device, which I
did
not like at all).

> > I will submit the full patches (diffs) if people agree that these changes
> > make sense. Or is there a better way to fix this problem?
>
> Well, yours will work only with one GPIB device support, so I think you
> have to stay with the above 'solutions', even though I dislike both of
> them.

For the GPIB, we clearly have to stay with those solutions. Now that the problems
are
more clear, I can go ahead with GPIB (although I share your disliking).
What I was more referring to was the motor control patch. There I dont see a
similar problem
with name clashes (experts, please correct me if I am missing something crucial
!), because the
called function is unique and handles any number of OMS58 cards. In this sense,
the motor
driver patch seems to be a more valid solution, although it would be cleaner to
keep the
function static,  if there was a way to make it work.

Timo

--
Timo Korhonen  PSI (Paul Scherrer Institut), SLS
               CH-5232 Villigen PSI
               tel + 41- 56 3103262  fax + 41 - 56 310 4413
e-mail:        [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System