Re: [Xenomai] Gpio-core question
On 11/29/2017 09:40 PM, Greg Gallagher wrote: > Hi, > Sorry for the formatting in the last email I'm not sure what > happened in my editor. I've had some time to look into this issue. > For my case that is outlined above it looks like we insert the fd into > the tree in create instance, then when we fail the call to > dev->ops.open, the fd is cleaned up with linux by using put_unused_fd > but we never remove it from the tree. On the next call to open we get > the same fd back from get_unused_fd_flags we then call create_instance > and fail because that fd is already in the tree from the previous > attempt. I'll test out my theory tonight. If this is what is > happening should the fd be removed from the tree in cleanup_instance? > I can play around with xnid_remove and see if working it into > cleanup_instance will solve the issue. You are definitely right. There should be an undo operation of rtdm_fd_enter() in __rtdm_dev_open() or __rtdm_dev_socket(), in the fail_open and fail_socket cases resp., along with dropping the file context via cleanup_instance(). Another option might be to make the undoing useless, by postponing the indexing until ->open() / ->socket() has returned successfully. To do that, we would have to split rtdm_fd_enter() in two functional steps instead of a single routine: 1- assign the default handlers, initializing the fd-> fields 2- index the rtdm_fd struct in the xntree. Then, we would keep on doing (1) at the end of create_instance(), waiting for the ->open() / ->socket() handler to return successfully before doing (2). I don't see any reason for ->open() or ->socket() to depend on the fact that rtdm_fd is already indexed on the ufd, which is a user-space handle anyway. Do you want to take a stab at implementing that stuff? -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] [PATCH] Fix compilation issues for the rest of RTNet drives
Hi, this patch lets compile RTNET drivers with 3.0.6 (kernel 4.9.51). I have done the same procedure as Robert Lange did before. Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- next part -- A non-text attachment was scrubbed... Name: 0007-rtnet-driver-fix-compilation-drivers.patch Type: text/x-patch Size: 11826 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20171130/fb120f43/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://xenomai.org/pipermail/xenomai/attachments/20171130/fb120f43/attachment.sig> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Virtualisation question
Hi, I know some companies are using some linux realtime environment virtualised inside a windows one. (or the reverse) ... Are there any people here that succeed with xenomai doing it .? Which best latency can I hope ? Regards, S.Ancelot ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Debian packages for Xenomai 3.x
Hi, if someone is interested I have been working a bit with the debian directory in xenomai3. I have changed the approach to the libraries. I think that now it has not sense to have a libxenomai1 so I have changed it to xenomai3-libs. The source, and the patches applied are here: https://anonscm.debian.org/cgit/collab-maint/xenomai.git/ In case there's some interest, I can try to push it again to the official Debian repositories. Best regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://xenomai.org/pipermail/xenomai/attachments/20171130/30845e41/attachment.sig> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] xeno-config options to build Xenomai applications
Hi, I think that this question has been answered partially in the list, but I would like to ask it with more detail to clarify and maybe rewrite for the documentation. I'm asking for applications in the user space, no kernel space. And cobalt core. Are these options correct? 1) Simple (C/C++) POSIX application with some threads. We want to use the POSIX functions as RT functions when possible. To compile: xeno-config --posix --cflags To link: xeno-config --posix --ldflags --auto-init 2) C/C++ POSIX shared library with some threads. We want to use the POSIX functions as RT functions when possible. To compile: xeno-config --posix --cflags To link: xeno-config --posix --ldflags --auto-init -auto-init-solib to build an application that uses that library: To compile: xeno-config --posix --cflags + normal cflags To link: xeno-config --posix --ldflags --no-auto-init + (ldflags of the library) 3) C/C++ POSIX shared library with native (2.x) (--alchemy) code and xddm mechanism to interchange data. The posix code must not be wrapped To compile: xeno-config --native --cflags --compat To link: xeno-config --native --ldflags --auto-init -auto-init-solib --compat to build an application that uses that library: compile and link with normal flags of the application to link against. Best regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://xenomai.org/pipermail/xenomai/attachments/20171130/ce0ad9cf/attachment.sig> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xeno-config options to build Xenomai applications
On 11/30/2017 01:32 PM, Leopold Palomo-Avellaneda wrote: > Hi, > > I think that this question has been answered partially in the list, but I > would > like to ask it with more detail to clarify and maybe rewrite for the > documentation. > > I'm asking for applications in the user space, no kernel space. And cobalt > core. > Are these options correct? > > 1) Simple (C/C++) POSIX application with some threads. We want to use the > POSIX > functions as RT functions when possible. > > To compile: xeno-config --posix --cflags > To link: xeno-config --posix --ldflags --auto-init Correct (also: --auto-init is assumed by default). > > 2) C/C++ POSIX shared library with some threads. We want to use the POSIX > functions as RT functions when possible. > > To compile: xeno-config --posix --cflags > To link: xeno-config --posix --ldflags --auto-init -auto-init-solib > --auto-init is for pure execs, which is mutually exclusive with --auto-init-solib which is for DSOs. xeno-config --posix --ldflags [--auto-init-solib] One needs --auto-init-solib to have the application attach to the Cobalt core (for gaining rt services) when it runs dlopen() on that library/DSO. The Xenomai code in charge of attaching the calling process to the rt core is contained in the bootstrap*.o files, one to be glued into pure execs, another one to be glued into PIC modules such as a DSOs. This configuration is typically useful with plugin architectures, which may dynamically load a Xenomai-dependent plugin to gain some rt services, but for which there is no point in having the main executable depend on or even know about Xenomai by construction. e.g. some language interpreter which can be dynamically extended by linking in rt features implemented in an external DSO. > to build an application that uses that library: > > To compile: xeno-config --posix --cflags + normal cflags > To link: xeno-config --posix --ldflags --no-auto-init + (ldflags of the > library) > Correct, if bootstrapping the Xenomai services for the process is done at some point though; like by passing --auto-init-solib for building a DSO this app depends on, as you originally mentioned. > 3) C/C++ POSIX shared library with native (2.x) (--alchemy) code and xddm > mechanism to interchange data. The posix code must not be wrapped > Assuming you meant: the posix code should not be wrapped (i.e. application requirement, not a Xenomai requirement). > To compile: xeno-config --native --cflags --compat > To link: xeno-config --native --ldflags --auto-init -auto-init-solib --compat > > to build an application that uses that library: > Correct, dropping --auto-init in this case though. > compile and link with normal flags of the application to link against. > > > Best regards, > > > Leopold > -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Gpio-core question
Sure sounds good, I'll start tonight. Original Message From: r...@xenomai.org Sent: November 30, 2017 3:50 AM To: g...@embeddedgreg.com; xenomai@xenomai.org Subject: Re: [Xenomai] Gpio-core question On 11/29/2017 09:40 PM, Greg Gallagher wrote: > Hi, > Sorry for the formatting in the last email I'm not sure what > happened in my editor. I've had some time to look into this issue. > For my case that is outlined above it looks like we insert the fd into > the tree in create instance, then when we fail the call to > dev->ops.open, the fd is cleaned up with linux by using put_unused_fd > but we never remove it from the tree. On the next call to open we get > the same fd back from get_unused_fd_flags we then call create_instance > and fail because that fd is already in the tree from the previous > attempt. I'll test out my theory tonight. If this is what is > happening should the fd be removed from the tree in cleanup_instance? > I can play around with xnid_remove and see if working it into > cleanup_instance will solve the issue. You are definitely right. There should be an undo operation of rtdm_fd_enter() in __rtdm_dev_open() or __rtdm_dev_socket(), in the fail_open and fail_socket cases resp., along with dropping the file context via cleanup_instance(). Another option might be to make the undoing useless, by postponing the indexing until ->open() / ->socket() has returned successfully. To do that, we would have to split rtdm_fd_enter() in two functional steps instead of a single routine: 1- assign the default handlers, initializing the fd-> fields 2- index the rtdm_fd struct in the xntree. Then, we would keep on doing (1) at the end of create_instance(), waiting for the ->open() / ->socket() handler to return successfully before doing (2). I don't see any reason for ->open() or ->socket() to depend on the fact that rtdm_fd is already indexed on the ufd, which is a user-space handle anyway. Do you want to take a stab at implementing that stuff? -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] matching patch version to kernel version
Hi, Steve. Steve Pavao writes: > I am building Yocto poky linux for an Intel board at head in Master > branch in Yocto poky, which currently results in a kernel version > 4.9.61. I stick to release branches for Poky for my own releases. Probably not a big deal, as my experience using HEAD on research projects hasn't been notably painful. > I see that the latest patch file in the xenomai download area is > ipipe-core-4.9.51-x86-4.patch. > > Will this patch work OK with the 4.9.61 kernel version, or should I use a > different approach to ensure a better match? You will need to edit the patch (I know from experience that there are definitely conflicting changes in between those points), but that's still -- probably -- your best bet. Since you don't care about ARM-specific files, I don't think you'll have too hard a time. Be well. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xeno-config options to build Xenomai applications
Hi, first of all thanks!! On 30/11/17 14:31, Philippe Gerum wrote: > On 11/30/2017 01:32 PM, Leopold Palomo-Avellaneda wrote: [] > >> 3) C/C++ POSIX shared library with native (2.x) (--alchemy) code and xddm >> mechanism to interchange data. The posix code must not be wrapped >> > > Assuming you meant: the posix code should not be wrapped (i.e. > application requirement, not a Xenomai requirement). ok, but could be any kind of conflict in the posix code is wrapped? xddm, etc? And just asking an idea. Could be possible "in theory" to build some big library as POCO to convert it to RT wrapping its POSIX funcions? I'm thinking in the thread class and the network module (RTNET) Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xeno-config options to build Xenomai applications
On 11/30/2017 03:41 PM, Leopold Palomo-Avellaneda wrote: > Hi, > > first of all thanks!! > > On 30/11/17 14:31, Philippe Gerum wrote: >> On 11/30/2017 01:32 PM, Leopold Palomo-Avellaneda wrote: > > [] >> >>> 3) C/C++ POSIX shared library with native (2.x) (--alchemy) code and xddm >>> mechanism to interchange data. The posix code must not be wrapped >>> >> >> Assuming you meant: the posix code should not be wrapped (i.e. >> application requirement, not a Xenomai requirement). > > ok, but could be any kind of conflict in the posix code is wrapped? xddm, etc? > With the app, could be. With the Xenomai libs, should not be as there are provisions for avoiding this by explicitly marking the POSIX calls there with either __RT() or __STD(). > > And just asking an idea. Could be possible "in theory" to build some big > library > as POCO to convert it to RT wrapping its POSIX funcions? I'm thinking in the > thread class and the network module (RTNET) > POSIX resources - sems, mutexes, condvars etc - can't be shared between rt and non-rt domains (i.e. cobalt and glibc), so blindly wrapping all POSIX calls may lead to unexpected results if there are calls on the same resources between those domains. Also, calling a non-wrapped portion of the library from a wrapped portion would defeat the purpose of switching the POSIX calls issued by the latter to Xenomai services. Wrapping should be handled on a case by case basis, I don't see any "automatic" process for this. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] matching patch version to kernel version
Hi, Lowell ! > On Nov 30, 2017, at 9:18 AM, Lowell Gilbert wrote: > > Hi, Steve. > > Steve Pavao writes: > >> I am building Yocto poky linux for an Intel board at head in Master >> branch in Yocto poky, which currently results in a kernel version >> 4.9.61. > > I stick to release branches for Poky for my own releases. > Probably not a big deal, as my experience using HEAD on research > projects hasn't been notably painful. I have been using poky pyro branch for all my previous releases, but the BSP layer for this particular board caused some unusual output warnings in an all-pyro build, so I opted for Poky Master branch at HEAD for this build, and did not experience the warnings. (I’m still trying trying to understand those warnings, so I can go back to using pyro branch.) I just noticed that a build done in pyro today resulted in a kernel version of 4.9.50. This is much closer to 4.9.51, so maybe applying that patch to the pyro branch would be less problematic. >> I see that the latest patch file in the xenomai download area is >> ipipe-core-4.9.51-x86-4.patch. >> >> Will this patch work OK with the 4.9.61 kernel version, or should I use a >> different approach to ensure a better match? > > You will need to edit the patch (I know from experience that > there are definitely conflicting changes in between those > points), but that's still -- probably -- your best bet. Since > you don't care about ARM-specific files, I don't think you'll > have too hard a time. I may need to do the patch for ARM-based targets as well, at some point. - Steve ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
