Jeff Hill wrote:
Should the release notes for R3.14 state that a site can get additional
memory for their memory limited vxWorks IOCs by not loading the vxWorks
symbol table and the iocCore symbol table into the target? Instead they
could link EPICS with vxWorks on the workstation and then not load the
symbol table into the IOC. This approach will be very similar to how
iocCore is run on the host so I suppose that a person might discuss that
this could be the default vxWorks configuration with R3.14 in order to
reduce additional operating modes and the EPICS learning curve. This
will of course require debugging remotely with the Tornado host based
shell and the Tornado source level debugger.
When we omit the symbol table the target shell becomes less useful if we
don't force a limited set of EPICS symbols to be loaded. We could, I
assume, use the iocsh to run the startup script, and use the host based
shell for diagnostics. It might also be nice to come up with an
attachment between iocsh and the vxWorks telnet server library so that
Tornado tools are not required to look into a normally functioning IOC
remotely.
The bottom line is that I can easily imagine that users with memory
limited vxWorks IOCs will be asking about this and therefore it might be
useful for someone to experiment enough so that we can decide if we
should support this in some way in makeBaseApp.pl.
Jeff
A few comments.
1) I will guess that very few EPICS users are using the tornado tools.
2) Many users use the vxWorks shell commands and rely on the symbol table being
present
3) I doubt that removing the symbol table completely solve the increased memory
uasge.
4)APS and I think most sites have terminal servers connected to the console
ports of each ioc. Thus we must create a completely new system for handling
reboots, etc
Marty
- References:
- stripping extranneous junk out of vxWorks IOCs Jeff Hill
- Navigate by Date:
- Prev:
stripping extranneous junk out of vxWorks IOCs Jeff Hill
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<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:
stripping extranneous junk out of vxWorks IOCs Jeff Hill
- Next:
The C10K problem Andrew Johnson
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|