> ...I feel that there _should_ be explicit control over whether
> output records read the VxWorks variable at initialization
> time. Also, I think that this is necessary in order to achieve
> backwards compatibility.
I don't think anyone ever set an output record to PINI=YES without
setting DOL, right? So ... if one uses a tool from the olden days (that
always puts something into DOL), everything will still work the same.
The only way to mess up things is using an editor or a new db generation
tool, not setting the DOL field and continue believing that this means a
CONSTANT 0. (Which isn't true anymore, anyway.) This would make the
record read the variable unintentionally.
Do you actually think someone might run into this?
> The result is that you can now use VxWorks global variable device
> support for direct access to device registers if you so desire.
Which (if the addresses are mapped to VME address space) - *sigh* - pops
up the topic of semaphore guarding again ... can you promise that all
kinds of VME accesses on all architectures using all the possible VME IO
cards are non-interruptable?
You should at least include a warning message in the doc (24pt bold red).
Ralph
- References:
- Re: VxWorks global variable device support William Lupton
- Navigate by Date:
- Prev:
gdct313 Linux executable ? Brian McAllister
- Next:
Re: VxWorks global variable device support William Lupton
- 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:
Re: VxWorks global variable device support William Lupton
- Next:
Re: VxWorks global variable device support William Lupton
- 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
|