Experimental Physics and Industrial Control System
|
Andrew Johnson wrote:
Till, Ernest,
Does what Eric describes provide what you guys need? The EPICS
rtems_netconfig.c file is really an application-specific network
configuration file so in many cases you may need to have your own anyway.
It just seems that rtems_netconfig.c mixes functionality of initializing
RTEMS
(networking, console, ...) and initializing EPICS (some generic things, some
os/RTEMS specific).
IMO it would be useful to break the two apart so that users implementing
their own RTEMS initialization can still use the pieces that deal with
initializing
EPICS (w/o having to copy/paste from rtems_netconfig.c).
- Till
- Andrew
Eric Norum wrote:
There are some mechanisms already available.
1) EPICS RTEMS support breaks the configuration/initialization into
several source files. If, for example, your application requires
some specialized network configuration, simply copy rtems_netconfig.c
to the application directory, make the changes, and add
rtems_netconfig.c to the application Makefile. To do this on a
site-wide basis, put your site-specific version of rtems_netconfig.o
into a support module where it will be linked before -lrtemsCom is
encountered. There's a separate rtems_config.c file, too.
2) As noted in the EPICS R3.14.10 release notes, there are some hooks
to make it easier to set up your own specific configuration:
Added hooks for application routines to supply special network
configuration parameters. The RTEMS startup code calls
epicsRtemsInitPreSetBootConfigFromNVRAM just before reading values
from NVRAM and epicsRtemsInitPostSetBootConfigFromNVRAM just
afterwards. See epicsRtemsInitHooks.h for prototypes and global
variables.
On May 1, 2008, at 4:10 PM, Andrew Johnson wrote:
Till Straumann wrote:
seems that 3.14.10 does a more initialization in the 'Init' function
which we don't use (e.g., because it hardcodes things like the the
amount of mbuf (networking buffers) space [which ends up
being the same] and whether BOOTP should be used.
IMHO we should come up with a better way of initializing the system
that is more flexible (here we use a bootloader plus a small library
for connecting the bootloader, user interactive input,
non-volatile memory
and the bootee).
For the time being, IMHO 'Init' should be broken up into pieces
that
a) deal with initializing RTEMS (networking, filesystem, console)
b) deal with initializing EPICS (setting some environment variables,
rtemsTicksPerSecond_double etc.)
The user should be able to override all of (a) but use (b) to
initialize
EPICS on an RTEMS system of her preference.
That seems entirely reasonable, can you work with Eric to come up
with a proposal and patch that works for both camps? R3.14.10 is
not set in stone yet, and it would be good to get this cleared up
before the release.
- Andrew
- Replies:
- Re: Unresolved symbol: rtemsTicksPerSecond_double Eric Norum
- References:
- Re: Unresolved symbol: rtemsTicksPerSecond_double Andrew Johnson
- Navigate by Date:
- Prev:
Re: Unresolved symbol: rtemsTicksPerSecond_double Andrew Johnson
- Next:
Re: Unresolved symbol: rtemsTicksPerSecond_double Eric Norum
- 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:
Re: Unresolved symbol: rtemsTicksPerSecond_double Andrew Johnson
- Next:
Re: Unresolved symbol: rtemsTicksPerSecond_double Eric Norum
- Index:
2002
2003
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 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|