On 13/01/2014 2:39 am, Philipp Eppelt wrote:
On 01/11/2014 11:50 PM, Chris Johns wrote:
On 12/01/2014 12:45 am, Philipp Eppelt wrote:
On 01/10/2014 10:27 PM, Chris Johns wrote:
On 7/01/2014 9:14 pm, Philipp Eppelt wrote:
On 01/07/2014 04:25 AM, Chris Johns wrote:
Does this include headers ?
POK separates kernel and partition code. The kernel code is not affected
by the partitions running on top. And each partition has the 'knowledge'
of how to communicate with the kernel. libpart.a consits of this
communication code or 'partition base code' and the implementation of
the functions in virtualizationlayercpu.h and virtualizationlayerbsp.h.
Or what do you mean with headers?
Where do the virtualizationlayercpu.h and virtualizationlayerbsp.h come
from and live ?
In libbsp/i386/virtualpok/include. The files are part of this patch.
What is used to build the library externally ?
I do not think having headers in RTEMS for a library built outside is a
good idea. An interface change in the library not reflected in RTEMS
headers will be difficult to find.
I prefer setting via configure and no other backdoor method such as
special files or environment variables. It makes configuration audits
much simpler.
If you need to switch versions when testing pok builds I suggest you use
something external to RTEMS. For example symlinks work where you
reference a symlink from RTEMS and move things as you want via the symlink.
On a second thought, the place of libpart in the users system shouldn't
change often. You first need to build the host environment for RTEMS
(POK) and then the location of libpart.a shouldn't change.
ToDo:
* extend --enable-paravirt to --enable-paravirt=/path/to/libpart.a
* what else?
Just the headers.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
