Re: A x86-64 port of nuttx with Linux compatibility layer
Seems I have finally got my apache list setup working properly. I think I need to make some clarification for my current directory setup in the repository. The idea was to minimize the modifications to both Linux and Nuttx while providing the ability to run them in parallel and accessing each other's benefit. Therefore, I used jailhouse hypervisor which is a simple hardware enabled partitioning hypervisor. Only bootloader is needed for porting a existing RTOS to jailhouse if the architecture is already supported by the RTOS. About the nuttx directories: * I tried not to modify the architecture independent part of nuttx, but I might did some in the early day of development, when I was using dynamic linking interface instead of system call interface. * arch/x86_64: contains my port of the x86_64 Nuttx, I tried to maintain the same directory structure as i486 port, but for x86_64, I really had a difficulty to separate common, intel64, broadwell architecture part perfectly. * arch/x86_64/src/linux_subsystem: This is where the Linux compatibility layer lives and licensing can be painful. * config/jailhouse-intel64: This directory contains the drivers and bootloader related to jailhouse. I tried to make a clean split of the Jailhouse related components and pure x86_64 part, but I might have failed some where. I do think that we can: 1. Find and revert any unnecessary change to the Nuttx kernel. 2. Clean up the arch/x86_64 code, decouple it from Jailhouse completely, and provide a qemu port. 3. Try to work out a working development environment with qemu, instead of jailhouse, for the sake that everyone can try it. (Because setting up Jailhouse is really a pain in the ass). 4. We can continue onto integrate the Linux compatibility layer and Linux binary loader after these are properly done. Yang -- Yang Chung Fan (楊宗凡) (ヤン ゾン ファン) Member of Softlab, Tsukuba University , Japan Email: sonic.tw...@gmail.com
Re: A x86-64 port of nuttx with Linux compatibility layer
On 2020/02/19 12:02:12, "Ishikawa, Masayuki (SHES)" wrote: > Hello, Yang, > > Nice to hear from you again and it's a great work. > We'd like you to talk about your work at NuttX 2020 in Tokyo. > > https://nuttx.events/call-for-participation/ > > Regards, > Masayuki > Yes, I am considering it. I have to check if this conflict with the ACM copyright first, because I do expect not much difference from current implementation and what is in may. --- Yang
Re: A x86-64 port of nuttx with Linux compatibility layer
> In that case, the NuttX RGMP support was in the NuttX repository but the > Linux RGMP support was elsewhere (you can still see the old NuttX RGMP > files here: > https://bitbucket.org/patacongo/obsoleted/src/83e33485517f2af145720b4ecd8a91158ccf506e/ChangeLog#lines-171). > > Perhaps we will need to make some separation of functionality like > that? I don't know what architectural separation you use now. I would > have to learn a lot more to give advice. I think a branch for discussion and interactive modifications is a good idea. I am having a difficult to create small incremental patches at this stage. I have kept the Linux part as clean as possible. Most of the implementation is in user-space. I uploaded the Linux side user-space program and kernel module code. https://github.com/sonicyang/cRTOS-Loader Hosting the Linux side on another repository might be cleaner to maintain, but might be difficult to integrate to the workflow here? The RGMP project like very similar to my research. I wounder how does its performance look like. --- Yang
Re: A x86-64 port of nuttx with Linux compatibility layer
Hi, Yang, I am glad to see that you have successfully completed your project and that you are contributing code to NuttX. For upstream, if each patch is small and independent, you can send PR directly to: https://github.com/apache/incubator-nuttx Or Greg could create a branch so you can do the work on that before it is ready. Separate PRs for each major functional change would make things easier too. I think that the basic x86_64 change could come in after some review. But I don't understand how the Linux/Jailhouse code with fit into the NuttX repositories. Perhaps we should create a branch in the upstream repository where we can review the code, check for coding style, review interfaces, make updates, etc. That when we all agree, merge the changes directly to master. In the past, NuttX supported the RGMP project: http://rgmp.sourceforge.net/wiki/index.php/Main_Page and http://rgmp.sourceforge.net/wiki/index.php/Running_NuttX_on_RGMP That was a different project but similar in that it had a NuttX component and a Linux component: It ran NuttX on one CPU of a multi-core CPU and Linux on another. RGMP provided the inter-CPU, inter-OS interface. In that case, the NuttX RGMP support was in the NuttX repository but the Linux RGMP support was elsewhere (you can still see the old NuttX RGMP files here: https://bitbucket.org/patacongo/obsoleted/src/83e33485517f2af145720b4ecd8a91158ccf506e/ChangeLog#lines-171). Perhaps we will need to make some separation of functionality like that? I don't know what architectural separation you use now. I would have to learn a lot more to give advice. Greg
Re: A x86-64 port of nuttx with Linux compatibility layer
Yang, Could you share more background information? we are very interesting the possibility to call Linux side API. For upstream, if each patch is small and independent, you can send PR directly to: https://github.com/apache/incubator-nuttx Or Greg could create a branch so you can do the work on that before it is ready. Thanks Xiang On Wed, Feb 19, 2020 at 2:07 PM Yang Chung Fan wrote: > > Hi, > > I have created a x86-64 port of Nuttx (tested with Xeon 2650 v4) along > with a Linux compatibility layer for my research. > > I would like to contribute the research artifacts to the upstream Nuttx. > I hosted the current code at github: > https://github.com/sonicyang/cRTOS > > The basic idea of my work is to run Nuttx and Linux side by side with > Jailhouse (or any other real-time hypervisor). > The Nuttx executes a process with handle the system calls. > If the system call does not exist, delegate to Linux. Let Linux do the > work for you. > (Of course, due to the semantics of system calls, some must be done in > Nuttx, e.g. clone(2)) > > Features high lights > * x86-64 port with MMU support > * Jailhouse hypervisor support > * Extended nanosecond clock accuracy > * Linux compatibility layer with system calls > * fork/clone support for processes. > * Remote exec for loading Linux ABI binaries > * Remote system call support for non-existing system calls. > > Some problem and questions for me to do this. > Questions: > * Besides the code formatting, another things I should do to my code? > * Any suggestions on how do I submit patch for this kind of large > piece of work? > * I have modified some internal parts of Nuttx, e.g. 16550 driver and > gran_allocator, etc. for extending their features and bug fix. Should > I submit them separately? > > Problems: > * There is code stolen from Linux(GPL) header and Jailhouse(GPL/MIT) > repo. I do think this cause a license conflict. (I have limited the > GPL affected file as 1) (As I remembered, I only used MIT code from > Jailhouse). > * Implementation is ugly. The x86-64 port is tightly coupled with > Linux compatibility layer and MMU support. > * Only Jailhouse support. (Theoretically, because jailhouse is a thin > partitioning hypervisor, this should also work directly on the actual > hardware.) Someone need to write a bootloader or multiboot2 support > for it. > * It is based on Nuttx 7.27, a bit old. > * The commit log is ugly and long, spanning the whole year 2019. > > I hope someone can give me instructions to upstream this work. > Any suggestions are welcome. > > The research result is being published as a paper in ACM VEE2020, > which will be held next month in Switzerland. > DOI: https://doi.org/10.1145/3381052.3381323 (should be active after > the conference 3/17/2020). > I will find somewhere legal to host the paper for everyone. > In short words, this method do better than most of existing Linux > real-time solutions while not losing the compatibility with Linux. > > -- > Yang Chung Fan (楊宗凡) (ヤン ゾン ファン) > Member of Softlab, Tsukuba University , Japan > Email: sonic.tw...@gmail.com
Re: A x86-64 port of nuttx with Linux compatibility layer
Hello, Yang, Nice to hear from you again and it's a great work. We'd like you to talk about your work at NuttX 2020 in Tokyo. https://nuttx.events/call-for-participation/ Regards, Masayuki On 2020/02/19 15:09, "Yang Chung Fan" wrote: Hi, I have created a x86-64 port of Nuttx (tested with Xeon 2650 v4) along with a Linux compatibility layer for my research. I would like to contribute the research artifacts to the upstream Nuttx. I hosted the current code at github: https://github.com/sonicyang/cRTOS The basic idea of my work is to run Nuttx and Linux side by side with Jailhouse (or any other real-time hypervisor). The Nuttx executes a process with handle the system calls. If the system call does not exist, delegate to Linux. Let Linux do the work for you. (Of course, due to the semantics of system calls, some must be done in Nuttx, e.g. clone(2)) Features high lights * x86-64 port with MMU support * Jailhouse hypervisor support * Extended nanosecond clock accuracy * Linux compatibility layer with system calls * fork/clone support for processes. * Remote exec for loading Linux ABI binaries * Remote system call support for non-existing system calls. Some problem and questions for me to do this. Questions: * Besides the code formatting, another things I should do to my code? * Any suggestions on how do I submit patch for this kind of large piece of work? * I have modified some internal parts of Nuttx, e.g. 16550 driver and gran_allocator, etc. for extending their features and bug fix. Should I submit them separately? Problems: * There is code stolen from Linux(GPL) header and Jailhouse(GPL/MIT) repo. I do think this cause a license conflict. (I have limited the GPL affected file as 1) (As I remembered, I only used MIT code from Jailhouse). * Implementation is ugly. The x86-64 port is tightly coupled with Linux compatibility layer and MMU support. * Only Jailhouse support. (Theoretically, because jailhouse is a thin partitioning hypervisor, this should also work directly on the actual hardware.) Someone need to write a bootloader or multiboot2 support for it. * It is based on Nuttx 7.27, a bit old. * The commit log is ugly and long, spanning the whole year 2019. I hope someone can give me instructions to upstream this work. Any suggestions are welcome. The research result is being published as a paper in ACM VEE2020, which will be held next month in Switzerland. DOI: https://doi.org/10.1145/3381052.3381323 (should be active after the conference 3/17/2020). I will find somewhere legal to host the paper for everyone. In short words, this method do better than most of existing Linux real-time solutions while not losing the compatibility with Linux. -- Yang Chung Fan (楊宗凡) (ヤン ゾン ファン) Member of Softlab, Tsukuba University , Japan Email: sonic.tw...@gmail.com
A x86-64 port of nuttx with Linux compatibility layer
Hi, I have created a x86-64 port of Nuttx (tested with Xeon 2650 v4) along with a Linux compatibility layer for my research. I would like to contribute the research artifacts to the upstream Nuttx. I hosted the current code at github: https://github.com/sonicyang/cRTOS The basic idea of my work is to run Nuttx and Linux side by side with Jailhouse (or any other real-time hypervisor). The Nuttx executes a process with handle the system calls. If the system call does not exist, delegate to Linux. Let Linux do the work for you. (Of course, due to the semantics of system calls, some must be done in Nuttx, e.g. clone(2)) Features high lights * x86-64 port with MMU support * Jailhouse hypervisor support * Extended nanosecond clock accuracy * Linux compatibility layer with system calls * fork/clone support for processes. * Remote exec for loading Linux ABI binaries * Remote system call support for non-existing system calls. Some problem and questions for me to do this. Questions: * Besides the code formatting, another things I should do to my code? * Any suggestions on how do I submit patch for this kind of large piece of work? * I have modified some internal parts of Nuttx, e.g. 16550 driver and gran_allocator, etc. for extending their features and bug fix. Should I submit them separately? Problems: * There is code stolen from Linux(GPL) header and Jailhouse(GPL/MIT) repo. I do think this cause a license conflict. (I have limited the GPL affected file as 1) (As I remembered, I only used MIT code from Jailhouse). * Implementation is ugly. The x86-64 port is tightly coupled with Linux compatibility layer and MMU support. * Only Jailhouse support. (Theoretically, because jailhouse is a thin partitioning hypervisor, this should also work directly on the actual hardware.) Someone need to write a bootloader or multiboot2 support for it. * It is based on Nuttx 7.27, a bit old. * The commit log is ugly and long, spanning the whole year 2019. I hope someone can give me instructions to upstream this work. Any suggestions are welcome. The research result is being published as a paper in ACM VEE2020, which will be held next month in Switzerland. DOI: https://doi.org/10.1145/3381052.3381323 (should be active after the conference 3/17/2020). I will find somewhere legal to host the paper for everyone. In short words, this method do better than most of existing Linux real-time solutions while not losing the compatibility with Linux. -- Yang Chung Fan (楊宗凡) (ヤン ゾン ファン) Member of Softlab, Tsukuba University , Japan Email: sonic.tw...@gmail.com
