EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: stripping extranneous junk out of vxWorks IOCs
From: Marty Kraimer <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Janet Anderson'" <[email protected]>, Andrew Johnson <[email protected]>, Eric Norum <[email protected]>, [email protected], Ralph Lange <[email protected]>
Date: Fri, 06 Dec 2002 07:59:24 -0600
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: <20022003  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: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·