Re: [Xenomai] core-3.5 for x86

[Wolfgang Mauerer <wolfgang.mauerer@siemens.com>]

On 20/12/12 17:25, Gilles Chanteperdrix wrote:
> On 12/20/2012 05:22 PM, Wolfgang Mauerer wrote:
>> On 19/12/12 22:06, Gilles Chanteperdrix wrote:
>>> On 12/18/2012 03:58 PM, Wolfgang Mauerer wrote:
>>>
>>>> On 18/12/12 15:47, Gilles Chanteperdrix wrote:
>>>>> On 12/18/2012 12:23 PM, Jan Kiszka wrote:
>>>>>> On 2012-12-15 20:16, Gilles Chanteperdrix wrote:
>>>>>>> On 12/15/2012 11:03 PM, Wolfgang Mauerer wrote:
>>>>>>>
>>>>>>>> Hi Gilles,
>>>>>>>>
>>>>>>>> On 15/12/2012 22:24, Gilles Chanteperdrix wrote:
>>>>>>>>
>>>>>>>>> I see some (recent) activity on this git repository:
>>>>>>>>> https://github.com/siemens/ipipe/commits/core-3.5_for-upstream
>>>>>>>>>
>>>>>>>>> In what state is this branch, can I pull from it?
>>>>>>>> please don't pull yet, I need to port a few more patches forward
>>>>>>>> and fix one known issue with the tree. But I'll try to send a
>>>>>>>> pull/discussion request next week.
>>>>>>>>
>>>>>>>>> At least the changes allowing preempt_disable()/preempt_enable() to be
>>>>>>>>> called from non-root context look dubious.
>>>>>>>> are you referring to 767f0d43fe3? This one still carries a TODO
>>>>>>>> item in the description to remind me to check with which
>>>>>>>> non-x86 archs this can cause problems, and what we can do about
>>>>>>>> them.
>>>>>>>
>>>>>>>
>>>>>>> Actually, we already have ipipe_safe_current(), so I guess what you need
>>>>>>> is ipipe_safe_current_thread_info() ?
>>>>>>
>>>>>> That cannot work unless you patch all the ftrace and perf stack - which
>>>>>> would surely not be a good idea /wrt maintainability.
>>>>>>
>>>>>> The point is remove the instrumentation from preempt_disable/enable at
>>>>>> least on those archs that do not need it. And then to look at the archs
>>>>>> that still have stack-based thread_info, if we cannot change this, at
>>>>>> least for CONFIG_IPIPE enabled.
>>>> are you talking about moving the arch's thread_info away from the stack
>>>> to some per-processor area like x86's PDA? At a first glance, that
>>>> sounds more invasive than changing preempt_xyz() in perf and ftrace
>>>> to me, especially since the changes to perf/ftrace should be fairly
>>>> straightforward -- just replace calls to preempt_xyz with calls
>>>> to preempt_xyz_save() based on ipipe_safe_current_thread_info().
>>>>
>>>> The easiest thing is to simply say that perf and ftrace are not
>>>> supported on archs that cannot reliably read thread_info from non-root
>>>> context, but that does not seem very attractive to me.
>>>
>>>
>>> What I am talking about is:
>>> - defining preempt_disable/preempt_enable to be
>>> ipipe_safe_preempt_disable/ipipe_safe_preempt_enable when CONFIG_FTRACE
>>> or CONFIG_PERF is on
>>> - for x86_64 (because even on x86_32, preempt_enable/disable use the
>>> stack pointer) definee ipipe_safe_preempt_disable/enable to be normal
>>> versions
>>>
>>> Now, if you think the implementation of
>>> ipipe_safe_preempt_disable/enable I propose for non x86 architectures is
>>> not what should be done, then do not define anything and generate a
>>> #error when ipipe_safe_preempt_disable/enable are not defined (and
>>> ftrace or perf are on).
>> no, your proposal is quite fine. But I guess it would be advantageous
>> if we could keep the root-only checks in all preempt code except
>> when employed for ftrace and  perf. This can be done by
>> exchanging the preempt_xyz() calls in the appropriate files to the
>> variants based on ipipe_safe_*(), and leave the rest unmodified.
>> How's that sound? I'm trying to finish the patch soon, but there are
>> unfortunately lots of other commitments towards the end of the year.
>
>  From what I understood from Jan answer, we want to avoid that for ease
> of maintenance.
I don't think maintenance would be so painful, so I'd like to at least
discuss the corresponding patch later.
>
>>
>>>
>>>>>
>>>>> The problem is the "then", we can not stay with a solution which works
>>>>> only for x86_64. The current contents of the github tree which disables
>>>>> the ipipe_root_context check on all architectures can not be merged as is.
>>>>
>>>> sure, the tree cannot be merged as is. That's why I asked for some more
>>>> time ;)
>>   >
>>> The thing is, I would like to release before next week-end... I know I
>>> have waited many monthes, but this has to take place at some point...
>>
>> oh, sorry, I was not aware of a release deadline. Knowing it would have
>> been beneficial for the planning... But if you want to release soon,
>> then how about just dropping support for ftrace and perf? I can prepare
>> a corresponding tree for this scenario if you like.
>
> It would be great, thanks.
okay, will do. Most likely not today, but tomorrow.

Best regards, Wolfgang
>