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 _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
