Kernel 2.6.12 + rtai3.x + adeos-linux-2.6.12-i386-r12.patch

[Philippe Gerum]

Paolo Mantegazza wrote:
> Philippe Gerum wrote:
> 
>> Paolo Mantegazza wrote:
>>
>>> Philippe Gerum wrote:
>>>
>>>> Paolo Mantegazza wrote:
>>>>
>>>>> Philippe Gerum wrote:
>>>>>
>>>>>> Hannes Mayer wrote:
>>>>>>
>>>>>>> Marcelo Coelho wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>>
>>>>>>>> I've tried to get the latest version of rtai, so i tried magma 
>>>>>>>> cvs. It compiled fine, no problems about "used_math" not 
>>>>>>>> existing, but when i load the modules i get a lot of unknown 
>>>>>>>> symbols, like per example with rtai_hal.ko
>>>>>>>>
>>>>>>>> rtai_hal: Unknown symbol adeos_extern_irq_handler
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Despite the prefix of the symbols, what you are using is not 
>>>>>> vanilla Adeos (adeos_extern_irq_handler is unknown from the 
>>>>>> vanilla implementation), but a hacked patch used since 3.2 and 
>>>>>> above, which is specific to the 3.x branch, and which merely 
>>>>>> removes Adeos's pipeline abstraction in favour of a direct 
>>>>>> handling of the interrupt sub-system by the RTAI 3.x core, instead 
>>>>>> of leaving this job to Adeos. This patch is usually called hal-*. 
>>>>>> Therefore, the answer to your question is likely in this mailing 
>>>>>> list's archive, regarding this specific series of patches, and has 
>>>>>> nothing to do with Adeos.
>>>>>>
>>>>>
>>>>> The above is a point of view, mine is different of course.
>>>>>
>>>>
>>>> Sure, but since I wrote the Adeos patch in the first place, I still 
>>>> feel entitled to define what its vanilla implementation is all about.
>>>>
>>>>> Suffice to say that the patches found in magma are just a few lines 
>>>>> added/changed (say 20 at most). They do no harm whatsoverto ADEOS. So
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This metric is irrelevant. 20 lines that basically hand the whole 
>>>> purpose of Adeos over another piece of code by intercepting the IDT 
>>>> vectors are something more than "a few harmless lines of code". This 
>>>> harms Adeos because now we have two patches series that pretend 
>>>> being the same and very hard times to explain why we have such fork 
>>>> in the first place to anyone reading this list.
>>>>
>>>> Proposing multiple solutions to a single problem is legitimate and 
>>>> even desirable for the sake of improvement, but in such a case, 
>>>> let's call a spade a spade: if two implementations have nothing in 
>>>> common, there is no reason to hide this fact.
>>>>
>>>>  after patching with the patches found in magma you can still do 
>>>> whatever
>>>>
>>>>> else can be done with ADEOS. Notably you can use both fusion and 
>>>>> rtai-classic.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Not relevant either; fusion could not make any use of the extra code 
>>>> introduced by those changes because it needs the pipeline 
>>>> abstraction, but would still pay the overhead of avoiding the added 
>>>> branches now plugged into the critical path. This is not a good deal.
>>>>
>>>>>
>>>>> In short it is an extension that allows an extended use of ADEOS 
>>>>> but has not been accepted by the ADEOS master.
>>>>>
>>>>
>>>> Adeos is based on the pipeline abstraction, having it is not an 
>>>> option, it's at the heart of the implementation. What remains used 
>>>> of Adeos in the hal-* patches is basically the machine takeover code 
>>>> given that everything else is hijacked to branch to the RTAI 3.x 
>>>> core instead of letting Adeos do the job, the rest being terminally 
>>>> dead code, so I'm still wondering why anyone would want to call this 
>>>> Adeos, and why the resulting patch keeps embarking such an amount of 
>>>> useless code.
>>>>
>>>
>>> That anyone is not me but Mr/s Performance.
>>
>>
>>
>> I have no problem with you building what you think is the best 
>> performing patch ever, I only have a problem with claims about this 
>> patch being your-regular-Adeos-with-only-a-few-anecdotal-changes, 
>> because as previously explained in details, it's not. And this 
>> particular claim is making my life as an Adeos maintainer more and 
>> more complex each day because more and more people send me "Adeos" bug 
>> reports until I finally figure out that what bugs them is in fact 
>> strictly concerning the hal-* patches, like the compilation issues 
>> which keep on being reported weeks after weeks. This is what I'd like 
>> to avoid, and it's simply avoidable by calling a spade a spade. Back 
>> to square #1.
>>
> 
> Here you are right absolutely.
> 
> So any RTAI-classic user adopting the latest of MAGMA should not bother 
> Philippe about ADEOS.
> 
> That for any architecture supported in MAGMA. In fact all of the so 
> called ADEOS like patches in RTAI, for ARM/x86/x86_64, are based on the 
> very same modified scheme.
> 
> So if you suspect that your problems are coming from those ADEOS like 
> patches found in magma refer to: myself, Mike and Daniele only.
> 

Thanks.

-- 

Philippe.