Hi, joel Our team is developing a pcie card running rtems. The stability is very important for us. Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc. "aarch64 on real hardware and SMP" is what we really wanted. Does this feature will be supported by rtems 5.x ?
small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 03:39 To: rtems-de...@rtems.org; David Edelsohn Subject: Planning for RTEMS 6 Branch Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
