Herman Bruyninckx wrote: > Dear list, > > I was wondering whether there is a new roadmap for the Xenomai project, now > that the split from RTAI is effective?
I'm not aware of any planned fundamental changes. Rather, Philippe was collecting ideas/wishes for the time after release 2.0. I already brought up some topics, and to take this chance, let's start collecting furthers: o ARM support It's burning in order to extend the usage to this booming domain. o More flexible scheduling subsystem This would allow to attach new scheduling schemes like EDF. And it should attract also more researchers to this project. Input from those people is valuable, because they tend to look from different perspectives at the code, finding different kind of bugs or optimisation potentials. o Define more RTDM device profiles, write more drivers With the availability of a driver model, I hope people will take the chance and broaden this important foundation part of any OS. I think the Xenomai community can become a very good arena for such efforts. Maybe we can even motivate some hardware vendors to jump in. o Consider new real-time memory allocators for the core I already had some discussions with Miguel Masmano, the maintainer of the quite promising TLSF allocator, about this. Further evaluation is certainly required, but his approach looks superior to the current BSD algorithm. > > In my contacts with industry, I feel that a clear roadmap and a clear > documentation and a clear design are paramount for getting credibility. And Yep, that's also what I hear from those people. I got the impression that the RTAI/fusion and now Xenomai approach is warmly welcome and already gained some credibility. > a top-notch POSIX implementation is also a must. I hope all these things > will (remain to) be priorities for "the new Xenomi"... > > If I may recommend one urgent action it would be to update the project's > home page at <http://home.gna.org/xenomai/>, and, especially, to remove the > rubbish from the mailing list announced on that page :-) > Give the maintainers at least a few days. ;) Anyway, the question arised for me if we really need to differentiate between a "core" and a "main" mailing list. According to the expected traffic volume and content, I configured my filter to forward both lists into the same inbox... Jan
signature.asc
Description: OpenPGP digital signature