Hi, I just want to keep this in the loop. Where do we want to draw the line between RTEMS and host systems?
Cheers, Philipp On 01/16/2014 02:53 PM, Philipp Eppelt wrote: > On 01/14/2014 08:36 PM, Chris Johns wrote: >> On 15/01/2014 1:58 am, Philipp Eppelt wrote: >>> On 01/14/2014 12:32 PM, Chris Johns wrote: >>>> On 14/01/2014 12:40 am, Philipp Eppelt wrote: >>>>> On 01/12/2014 10:19 PM, Chris Johns wrote: >>>>>> 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. >>>>> >>>>> The header files define the virtualization layer in RTEMS. They are not >>>>> part of POK. >>>> >>>> Yet the code is built by POK. I am a little confused by this. >>>> >>>>> The header files define the functions a host has to >>>>> implement to run this particular RTEMS BSP. >>>> >>>> Sure. >>>> >>>>> All hardware interactions a BSP/CPU does go through this layer and are >>>>> handled on the host system. RTEMS defines the function necessary and >>>>> POK >>>>> is providing the implementation via libpart.a. >>>> >>>> How does POK see these definitions so it can build the library ? >>> Copy & Paste. >>> I kept the two systems separated and I think gcc, couldn't resolve links. >>> >> >> This is what I suspected and my concern. The library and header files >> need to be in a single location together so users do not get mismatches >> if anything changes. > We should put this into the troubleshooting section of the README file. > If you are running RTEMS on POK, I assume you know what you are getting > yourself into and therefore read the README? > >> >>>> >>>>> >>>>> For examples, the console driver calls _BSP_Virtual_Char_read/write, >>>>> defined in virtualizationlayerbsp.h. >>>>> The implementation is done in POK and passed to RTEMS at compile time >>>>> via libpart.a >>>> >>>> What is the interface used in POK to build this RTEMS interface ? >>> What do you mean? >>> >>> The header files are written for RTEMS >> >> This is what I mean by the POK/RTEMS interface. I suspect my wording was >> not correct before. >> >>> , so the compiler has something to work with. >> >> I assume you mean the POK compiler to build the library as part of POK >> and also the RTEMS compiler as part of RTEMS to reference the library. >> Is this true ? > Yes. > >> >>> The linker uses the library provided by POK to resolve the >>> undefined references. >>> The POK implementation includes a copy of these header files. Hence, the >>> linker can match the names. >> >> Why not move this libpart code in RTEMS. I assume it just needs to >> reference POK system call interfaces which I assume are standard and do >> not change ? > I introduced some new system calls to POK, as POK was not able to attach > partitions to interrupt sources. I would say it is not likely to change > often, but it does change from time to time. > Currently, libpart.a includes everything a POK partition is configured > for, so RTEMS compiles a valid POK partition. > Looking at my source code[0] I agree, that it is only using the syscall > interface (printf l.117 can directly be replaced by a syscall). But if > we want to use communication functionality with other partitions in the > system (e.g. network card driver), we have to pull a lot of stuff into > RTEMS[1]. > > In the design I made the distinction between host world and RTEMS world. > And in the RTEMS world I don't want to care about how exactly the > message gets to the network driver, I just want to invoke one function. > The rest is dependent on the host system and therefore nothing I should > be bothered with. > By now, we know we will end up with one BSP per host per architecture, > but I still think, the host implementation should stay on the host side. > Hence, libpart.a is implemented in POK. > > As we end up with one BSP per host, one could argue, to expand the host > specific part of the virtualization layer into the BSP. But then we have > to track the changes in a foreign project and not just update the host > implementation, when we change something. > But the stronger argument from my point of view is the transparent > implementation of the layer. > > > Cheers, > Philipp > > > [0] https://github.com/phipse/pok/blob/master/examples/rtems-guest/hello.c > [1] https://github.com/phipse/pok/tree/master/libpok > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
