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
