Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Nitpicking: if you intend to push this material to me at some point, please make sure to prefix commit subject lines with 'ipipe:' for the -noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and this 'tends' to conform to linux mainline as well. Jan -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Ah, so you mean a generic parameter check in ipipe_send_ipi for those 4 IPIs is possible? Then I will add a corresponding patch to the generic queue. Nitpicking: if you intend to push this material to me at some point, please make sure to prefix commit subject lines with 'ipipe:' for the -noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and this 'tends' to conform to linux mainline as well. OK, will fix. And if I had a wish for the maintainer: Please ensure that the -noarch branch in kept in proper sync with the latest arch. Took me a while (and two temp branches) to extract a proper x86-only patch for the port. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Actually, the more I think of it, the less I see the value of checking the parameter passed to such an internal call like __ipipe_send_ipi(). There is no user interaction with this code. So removing the test is indeed better. Nitpicking: if you intend to push this material to me at some point, please make sure to prefix commit subject lines with 'ipipe:' for the -noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and this 'tends' to conform to linux mainline as well. Jan -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
Philippe Gerum wrote: On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Actually, the more I think of it, the less I see the value of checking the parameter passed to such an internal call like __ipipe_send_ipi(). There is no user interaction with this code. So removing the test is indeed better. Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if at all, then here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Btw, could you pick Wolfgang's host rt clock patch in your queue as well? I only have a few minor issues with it, which are no showstopper. The only thing to care of before merging this to mainline, is that no other arch does support this feature yet, so it is important to make it fully optional in -noarch, and Xenomai-wise also. We likely need some __IPIPE_FEATURE_* symbol to be defined in arch/x86/include/ipipe_base.h for this purpose, so that depending code could test for presence. I'll pull the whole thing from your tree when x86_32 is known to rock as well. Looking forward to feedback, Jan -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Btw, could you pick Wolfgang's host rt clock patch in your queue as well? I only have a few minor issues with it, which are no showstopper. The only thing to care of before merging this to mainline, is that no other arch does support this feature yet, so it is important to make it fully optional in -noarch, and Xenomai-wise also. We likely need some __IPIPE_FEATURE_* symbol to be defined in arch/x86/include/ipipe_base.h for this purpose, so that depending code could test for presence. Will have a look. There is one further feature on my to-do list anyway: KVM support. Will also require a feature bit (for a new root preemption notifier). I'll pull the whole thing from your tree when x86_32 is known to rock as well. OK, great. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote: Philippe Gerum wrote: On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Actually, the more I think of it, the less I see the value of checking the parameter passed to such an internal call like __ipipe_send_ipi(). There is no user interaction with this code. So removing the test is indeed better. Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if at all, then here. Yes, ipipe_send_ipi() is the public API, calliong into __ipipe_send_ipi() for a per-arch implementation; I messed up in my explanation. My point is that your idea to remove the check from __ipipe_send_ipi seems correct to me, since nobody should send a silly value to this internal call. The test should be done in ipipe_send_ipi() once for all, relying on the generic names of the IPIs. Regarding those names, and unlike I initially thought, ppc64 is still preventing me from removing IPI4 in 2.6.35, so I guess that for implementing a generic test, we would have to resort to #ifdef pollution. Jan -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
Philippe Gerum wrote: On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote: Philippe Gerum wrote: On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Actually, the more I think of it, the less I see the value of checking the parameter passed to such an internal call like __ipipe_send_ipi(). There is no user interaction with this code. So removing the test is indeed better. Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if at all, then here. Yes, ipipe_send_ipi() is the public API, calliong into __ipipe_send_ipi() for a per-arch implementation; I messed up in my explanation. My point is that your idea to remove the check from __ipipe_send_ipi seems correct to me, since nobody should send a silly value to this internal call. The test should be done in ipipe_send_ipi() once for all, relying on the generic names of the IPIs. Regarding those names, and unlike I initially thought, ppc64 is still preventing me from removing IPI4 in 2.6.35, so I guess that for implementing a generic test, we would have to resort to #ifdef pollution. Can we require that the IPI numbers are consecutive? Then the arch could define an upper limit, and we could do a nicer range check in the generic code. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86
On Tue, 2010-08-24 at 19:14 +0200, Jan Kiszka wrote: Philippe Gerum wrote: On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote: Philippe Gerum wrote: On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote: On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote: Hi, just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai head, but I only ran light tests so far. Anyone interested in upgrading the host kernel (I think I read some request recently) is welcome to give it a try and report results back (specifically on 32 bit as that is a bit out of focus for me ATM). You can download the full git tree from git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86 (alternatively also via http://) Looking forward to feedback, The comment and the relevant code for 82a7dd3df needs fixing: all pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3]. powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in 2.6.35. The upcoming arm/SMP port conforms to this requirement as well. Those are merely pipelined IPI channels, the way the arch-dep section manages to multiplex them (or not) over the available hw channel(s) is of course unspecified. The virtual IPI numbers are also unspecified. Actually, the more I think of it, the less I see the value of checking the parameter passed to such an internal call like __ipipe_send_ipi(). There is no user interaction with this code. So removing the test is indeed better. Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if at all, then here. Yes, ipipe_send_ipi() is the public API, calliong into __ipipe_send_ipi() for a per-arch implementation; I messed up in my explanation. My point is that your idea to remove the check from __ipipe_send_ipi seems correct to me, since nobody should send a silly value to this internal call. The test should be done in ipipe_send_ipi() once for all, relying on the generic names of the IPIs. Regarding those names, and unlike I initially thought, ppc64 is still preventing me from removing IPI4 in 2.6.35, so I guess that for implementing a generic test, we would have to resort to #ifdef pollution. Can we require that the IPI numbers are consecutive? Then the arch could define an upper limit, and we could do a nicer range check in the generic code. Sure. In fact, ipipe_ipi_p() testing this would be just as nice. Jan -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
