Re: [Xenomai] [RFC] dropping ppc64 support
Hi all, dropping the ppc64 support are bad news for me. Watchting the xenomai project for several years, I'm now in the situation for the need of a stable hard rt solution in combination with gnu/linux for a project. So xenomai is no longer on the list, due to the missing future support for ppc64. Any suggestions which way to go? The PREMEPT_RT is definitly no way to go. My last idea is to go for Jailhouse with GNU/Linux and RTEMS. -- Wolfram Wadepohl Projektmanager Automatisierung & Robotik Phone +49 (0)7123 164-2062 Mobile +49 (0)160 9531 5679 > -Original Message- > From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Philippe > Gerum > Sent: Thursday, January 25, 2018 6:41 PM > To: Henning Schild; Jan Kiszka; Sebastian Smolorz; Jan Leupold; Jorge Ramirez > Cc: Steven Seeger; Xenomai@xenomai.org > Subject: [Xenomai] [RFC] FOSDEM meeting agenda > > * formalizing the decision about dropping the blackfin and powerpc64 > port, since we had zero feedback from users so far, so everyone must be fine > with this. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] meeting agenda suggestions
Adding some points that I think need some attention at the meeting. Drivers: Currently we have support for certain boards, SOC families and devices. Do we want to expand on that? Are there commonly used pieces of hardware that we want to add support for? For most devices it may be a port from Linux to Xenomai, which could be low effort. What drives improvements to our current frameworks like gpio and spi ? Adding i2c, pwm and pci devices (etc) may be helpful. Are users looking for full BSPs? Reference Boards: Projects like AGL (Automotive Grade Linux) use low cost boards as reference platforms so potential customers can get up and running quickly. I really think this helps for prototyping. There's already some support for Raspberry Pi, we could expand on that. We could look at the beaglebone family of boards and potentially Zynq boards. Quick Start Guide: This would probably fall under documentation but putting together a quick start guide for new users may be worthwhile. It could be tied into the above comment of using low cost boards and we focus on a quick start guide for one or two community (low cost) boards. "How to" Articles: This may go with the above point, but adding some type of doc that shows how to properly use the gpio, udd, ipc and other sub systems would help new users and people possibly evaluating Xenomai. Having these on the homepage I think would show potential users that there are resources to help get them started. It would give prospective users a general idea of what features Xenomai supports so far. They could also serve as reference/example code. Testing: How do we test Xenomai? There's some documentation on smokey the smoke test framework, when are those tests run and how often? Do we run those tests across all architectures? Is a regression test suite something we want to build? Any reported bugs can be made into a test case and added to the regression tests. Bug reporting: When a user reports a bug on the mailing list they usually don't include all the information needed. There has been discussion on using a bug tracking system. Is this part of the gitlab effort? it would be nice to ask the users for example code to reproduce their bugs. The udd issue on the todo list is hard to reproduce since there is only snippets of code in the email thread and not a lot of information on what the kernel side of the udd driver does. We can also see if anyone is watching or currently working on the bug. Xenomai's successes: We could give community members and companies the opportunity to post their product or creation somewhere on the Xenomai home page. It would give potential users the ability to see Xenomai's successes. Thanks, Greg ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] [RFC] FOSDEM meeting agenda
Here are some points I would like to discuss during this meeting. Please feel free to comment: 1. Release management * Currently, the person who contributes most of the code is also the release manager, which is clearly not optimal. Both activities should be decoupled for efficiency (esp. hindsight) and practical reasons. At some point, I will stop acting as the release manager, so the project will need a different organization in this respect. Which one? * As a corollary, the current release process is broken: no explicit release plan or schedule, limited testing, barely any user feedback about the development version in general. Practical steps to improve this should be discussed. * My understanding is that v3.1 is almost there feature-wise, with a working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually enabling RTnet with SMAP/x86 (which still need some feedback btw), and support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is still lagging behind with kernel 4.9 though. I'm about to queue a couple of ABI changes more, with the implementation of sendmmsg() and recvmmsg() for RTDM sockets. This raises the following questions: 1) may we freeze the v3.1 ABI, 2) should we wait for supporting 4.14/x86 before releasing v3.1, 3) how much use/testing do we currently have of the -next branch, on which CPU architecture(s)? 2. Documentation * The existing documentation has several weaknesses; from the traffic on the mailing list, the main one may be that it leaves newcomers with a steep learning curve, in some occasions, even when the information is published on the website and/or present in the inline documentation. How to improve the situation, how to better organize the existing doc so that people do find what they are looking for? * Doxygen may not be the best option anymore for inline documentation; Chasing glitches with using the markup has been a real pain over the years, getting properly structured output has never been obvious. Could we do better with Doxygen in a reasonably simple fashion, or should reStructuredText and Sphinx be considered as a replacement, so that we can converge toward the kernel documentation system? 3. Pipeline maintenance * We now have a dedicated I-pipe maintainer per CPU architecture, which is a great relief to me. Now I'd like we discuss the maintenance process, 1) how to organize the upstream/downstream flow of the generic pipeline bits I still maintain currently, between other maintainers and me? 2) how to best disseminate knowledge about the I-pipe implementation? * mainline vs CIP kernel, LTS maintenance policy 4. Misc * formalizing the decision about dropping the blackfin and powerpc64 port, since we had zero feedback from users so far, so everyone must be fine with this. Thanks, -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Posix vs Alchemy - multiplexing and registry
On 01/25/2018 04:14 PM, Julien Blanc wrote: > Le jeudi 25 janvier 2018 à 15:21 +0100, Philippe Gerum a écrit : >> On 01/25/2018 02:43 PM, Julien Blanc wrote: >>> >> There is no provision for I/O multiplexing with alchemy. Only the >> pipe object embeds a RTDM file descriptor which could be passed to >> libcobalt's select() implementation, other resources (e.g. queues, >> buffers etc) don't. > > Thanks for your answer. If i understand correctly, this also means that > it is not recommended to mix both APIs in the same program. For example > a queue created with rt_create_queue cannot be read with > __cobalt_mq_open, am I right ? Correct. One may use both POSIX and alchemy APIs in the same program though, but calls referring to equivalent objects (e.g. sem, queue, task/threads, etc) are not interchangeable. alchemy provides high-level services built on basic POSIX calls. > >> I would suggest to enable the registry for your application (not for >> the entire POSIX API), as you might not need each and every resource >> to be exposed via a fuse-based fs. > > This is something i'd rather avoid if possible. Though, thanks for the > pointers, at first glance it seems much simpler than what i feared. > It is pretty simple, just not documented. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Posix vs Alchemy - multiplexing and registry
Le jeudi 25 janvier 2018 à 15:21 +0100, Philippe Gerum a écrit : > On 01/25/2018 02:43 PM, Julien Blanc wrote: > > > There is no provision for I/O multiplexing with alchemy. Only the > pipe object embeds a RTDM file descriptor which could be passed to > libcobalt's select() implementation, other resources (e.g. queues, > buffers etc) don't. Thanks for your answer. If i understand correctly, this also means that it is not recommended to mix both APIs in the same program. For example a queue created with rt_create_queue cannot be read with __cobalt_mq_open, am I right ? > I would suggest to enable the registry for your application (not for > the entire POSIX API), as you might not need each and every resource > to be exposed via a fuse-based fs. This is something i'd rather avoid if possible. Though, thanks for the pointers, at first glance it seems much simpler than what i feared. Regards, Julien ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Posix vs Alchemy - multiplexing and registry
On 01/25/2018 02:43 PM, Julien Blanc wrote: > Hi, > > We have a xenomai 3 application currently using the alchemy API > (application development started on xenomai 2.x). > > We would like to add I/O multiplexing in some parts of the application. > My understanding is that it is not supported by the alchemy API, so we > would have to resort to the Posix API. > > The downside is that by doing so, we lose the registry : with the posix > api nothing is exported. We would like to access all this data, at > least for debugging purposes (ideally, disable it in production build). > > I couldnt find any pointer for doing either of the following : > - enable the registry while using the posix API > - multiplex using the alchemy api > - retrieve a posix-api compatible file descriptor from an alchemy > handle (which would allow a __cobalt_select call) > > Is there some resources or something obvious that i'm missing ? > There is no provision for I/O multiplexing with alchemy. Only the pipe object embeds a RTDM file descriptor which could be passed to libcobalt's select() implementation, other resources (e.g. queues, buffers etc) don't. I would suggest to enable the registry for your application (not for the entire POSIX API), as you might not need each and every resource to be exposed via a fuse-based fs. To do so, you can link against libcopperplate, which is not documented. However, looking at lib/alchemy/init.c may give you some hints about the way to create your own registry hierarchy (see alchemy_init()). Then looking at sections defined for CONFIG_XENO_REGISTRY in e.g. queue.c would give you an illustration of a proper client-side usage, for populating this hierarchy with object nodes, and the way to return information back when those nodes are opened for reading. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Posix vs Alchemy - multiplexing and registry
Hi, We have a xenomai 3 application currently using the alchemy API (application development started on xenomai 2.x). We would like to add I/O multiplexing in some parts of the application. My understanding is that it is not supported by the alchemy API, so we would have to resort to the Posix API. The downside is that by doing so, we lose the registry : with the posix api nothing is exported. We would like to access all this data, at least for debugging purposes (ideally, disable it in production build). I couldnt find any pointer for doing either of the following : - enable the registry while using the posix API - multiplex using the alchemy api - retrieve a posix-api compatible file descriptor from an alchemy handle (which would allow a __cobalt_select call) Is there some resources or something obvious that i'm missing ? Best regards, Julien ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
