From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesper Skov <jskov@redhat.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Virtual vectors initialization changed
Date: Thu, 01 Feb 2001 05:43:00 -0000
Message-id: <200102011343.f11Dhbb01711@host176.cambridge.redhat.com>
X-SW-Source: 2001-02/msg00002.html

Hi

Just a quick note to make people aware of some changes in the way the
virtual vectors get initialized.

Previously, the entire table of virtual vectors would get initialized
in configurations containing the GDB stubs code, or if configured for
ROM startup.  That is, ROM monitors (or equivalent RAM startup
configs) were forced to initialize the table, and regular RAM startup
configurations were forced to use the table as already initialized.

That was unfortunate, most of all because it made it unclear what the
virtual vectors are there for. To set the record straight:

 virtual vectors: are a _mechanism_ for allowing services in the table
                  to be implemented in a different "address space"
                  than the callers. Primarily to allow RAM
                  applications to use services provided by a ROM
                  monitor.

When and how to initialize the table is a _policy_ which is now
controlled with much higher granularity. Specifically, the new code
checked in (which will be available via public CVS on Friday, giving
me a day to sort out any unforseen quirks), will allow better control
of:

 o  When the virtual vector table gets initialized. Regular RAM
    configuration can now to do so if desired - allowing for testing
    of new implementations of the various services.

 o  Which services to provide in a RAM configuration - e.g., only
    override the reset vector to test new implementation while relying
    on IO services provided by the ROM monitor.

Also the defaults are to initialize as much of this table as makes
sense (everything but IO since those might already be in use by
debugger connection). This means that the bulk of the code gets tested
in normal builds, and not just once in a blue moon when building new
stubs or a ROM configuration.


The CDL comes with comments, of course. But I will also be updating
the virtual vectors overview/introduction in the porting guide to
match.

The changes are pretty much contained to the common HAL, but I have
also removed the IMPLEMENT_IF_SERVICES option which was used in
platform HALs before to control compilation of IO code. Again, this is
to ensure continual (compile) testing of code.


I have some related changes pending for controlling when/how to update
the communication channels, but this needs a little more work. This is
what will allow proper control of GDB O-packet mangling and allow diag
output over ethernet. But I'll post a separate notice when that goes
in.

Cheers,
Jesper