[Xenomai-core] [PATCH 0/5] Xenomai patch queue

[Xenomai-core] [PATCH 0/5] Xenomai patch queue

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Hi,

while the syscall tracing thing still puzzles me, I was now at least
able to check that my patches do what they are supposed to. So here
comes a flush of (most of) the stuff that piled up on my side, fixing or
enhancing the following aspects:

 - x86 hal refactoring (-v2) - I decided to base my work on this because
   it shakes the code anyway and also happens to touch hal stuff, thus
   benefits from the unified version.

 - get timer frequency from ipipe (thus Linux) instead of relying on
   home-brewed estimations (fixes inaccurate APIC frequency)

 - report configured timer and clock device via /proc/xenomai/timer

 - cleanup tickdev emulation (related to I-pipe refactorings)

 - provide for __must_check attribute for __xn_copy_*_user services
   (developer tool - not for merge yet!)

I-pipe changes for i386 and x86_64 will be sent separately.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [PATCH 0/5] Xenomai patch queue

[Philippe Gerum]

Jan Kiszka wrote:
> Hi,
> 
> while the syscall tracing thing still puzzles me, I was now at least
> able to check that my patches do what they are supposed to. So here
> comes a flush of (most of) the stuff that piled up on my side, fixing or
> enhancing the following aspects:
> 
>  - x86 hal refactoring (-v2) - I decided to base my work on this because
>    it shakes the code anyway and also happens to touch hal stuff, thus
>    benefits from the unified version.
> 
>  - get timer frequency from ipipe (thus Linux) instead of relying on
>    home-brewed estimations (fixes inaccurate APIC frequency)
> 
>  - report configured timer and clock device via /proc/xenomai/timer
> 
>  - cleanup tickdev emulation (related to I-pipe refactorings)
>

Looks good. I will not even make a fuss about the ipipe_request_tickdev
API breakage (surprise, surprise...), since we should be able to avoid
the nuisance with proper detection of new I-pipe patches. To this end,
I'm going to introduce a known feature list as defines in new Adeos
releases, so that downstream may rely on their presence for proper
feature selection. This should hopefully help normalizing such kind of
detection code.

Will merge asap, to be included in -rc7 since most of the patch is about
moving code around to streamline the x86* HAL support.

Thanks,

-- 
Philippe.