Philippe Gerum wrote:
> On Sat, 2006-12-02 at 18:37 +0100, Wolfgang Grandegger wrote:
>> Philippe Gerum wrote:
>>> On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote:
>>>> Philippe Gerum wrote:
>>>>> On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote:
>>>>>> On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote:
>>>>>>> Anyway, there is an unreleased work-in-progress patch for x86 over -rc6
>>>>>>> by Philippe. I recently had the chance to test it and hack a bit on the
>>>>>>> SMP IO-APIC part. It seems to work fine under UP, but SMP had some
>>>>>>> issues that are identified, but still need to be addressed - thanks to
>>>>>>> genirq, now in a widely arch-independent way.
>>>>>>> Philippe, I know you are very busy, but shouldn't we make a pre-release
>>>>>>> available already, also to discuss further how to deal best with genirq
>>>>>>> on other platforms beyond x86?
>>>>>> Actually, the draft patch I sent you did not boot on my SMP box today,
>>>>>> so qemu seems to have been a bit too friendly. Knowing that, issuing a
>>>>>> half-baked patch would have made no sense, so I finally refrained from
>>>>>> doing that. Since I'm now basically in love with the genirq layer (at
>>>>>> least for x86) compared to the utter mess that we had to endure
>>>>>> previously, I've decided to tackle the issue completely, and rewrite the
>>>>>> I-pipe interrupt flow in order to leverage it. Will post something asap.
>>>>> Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been
>>>>> tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron
>>>>> 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far,
>>>>> and even passed the horrid "dohell" test on the SMP box, just smiling.
>>>>> However, I don't have the required hw at hand to check if our friend the
>>>>> MSI support is not killing us once more. This said, the MSI support in
>>>>> 2.6.19 also conforms to the genirq specs, so there's hope.
>>>>> The patch is available from the Adeos download area, and I've also
>>>>> committed it to the SVN trunk/.
>>>>> Feedback welcome,
>>>>> PS: I have the corresponding quilt-managed patches available upon
>>>>> request, to the people who want to use this work as a reference for
>>>>> porting to other archs.
>>>> You mean that you have separate patches for the common and arch 
>>>> dependent part.
>>> Mostly, yes. The patches are split by function, but this usually
>>> correlates with the noarch / arch-specific break down view too.
>>>>  That would be nice. I'm interested!
>>>>  As a consequence we 
>>>> could provide separated patches in general and applies 
>>>> them in sequence. Just an idea for the future.
>>> Problem is that we would have to store a set of patches for each Adeos
>>> version/arch combo, instead of a single one. What advantage do you see
>>> in breaking the Adeos patches down for
>> Maintenance issues for the noarch part, e.g., if you fix a bug in the 
>> common part or add new features it's available for all arch.
> I think this should be easier once we have moved to git, pulling commits
> is made simple (yeah, I'm late on this too...)

Ah, I just read the keyword: git! ;)

Rough idea from my side on a potential organisation of the git trees:

 o A generic I-pipe core tree that primarily targets git head (i.e. 2.6)
 o One branch for git head, pulls both from Linus' tree and the I-pipe
 o One tree for each major 2.6 version in maintenance mode, pulls from
   related stable branch and I-pipe core (when applicable)
 o Only if required: a generic I-pipe core tree for 2.4
 o One tree for 2.4 head to maintain x86
 o One tree for 2.4 ELDK to maintain PPC

Quite a lot trees... Do you this this may work?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to