Am 21.01.2013 um 13:17 schrieb John Kacur:
> On Mon, Jan 21, 2013 at 1:14 PM, Michael Haberler <mail17@xxxxxxxxxxx> wrote:
>> John,
>>
>>
>> Am 21.01.2013 um 12:36 schrieb John Kacur:
>>
>>> On Sun, Jan 20, 2013 at 9:18 PM, Carsten Emde <C.Emde@xxxxxxxxx> wrote:
>>>> John,
>>>>
>>>>
>>>>>>>> Unfortunately, this wiki article is old and unmaintained. You're
>>>>>>>> probably right to be a bit suspicious when checking for the "-rt"
>>>>>>>> suffix
>>>>>>>> of the kernel release (uname -r). But looking for the occurrence of
>>>>>>>> "PREEMPT RT" in the kernel version (uname -v) should work. An
>>>>>>>> application may use the system call uname() and check the version
>>>>>>>> element of the utsname structure.
>>>>>>>
>>>>>>> the utsname.version string match is fine, however:
>>>>>>>>
>>>>>>>> In addition you may want to make sure the system has
>>>>>>>> high-resolution
>>>>>>>
>>>>>>> timers. If so, the timers in /proc/timer_list have ".resolution: 1
>>>>>>> nsecs". An application may use the function check_timer() from
>>>>>>> cyclictest for this purpose:
>>>>>>>>
>>>>>>>> static int check_timer(void)
>>>>>>>> {
>>>>>>>> struct timespec ts;
>>>>>>>>
>>>>>>>> if (clock_getres(CLOCK_MONOTONIC, &ts))
>>>>>>>> return 1;
>>>>>>>>
>>>>>>>> return (ts.tv_sec != 0 || ts.tv_nsec != 1);
>>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Just tried this on a generic kernel (2.6.32-45-generic #102-Ubuntu
>>>>>>> SMP Wed Jan 2 21:53:06 UTC 2013 i686 GNU/Linux) and I get ts.tv_sec == 0
>>>>>>> and ts.tv_nsec == 1, so it looks this cant be used to tell an RT_PREEMPT
>>>>>>> from a vanilla kernel
>>>>>>
>>>>>> I meant boolean AND when I said "In addition".
>>>>>
>>>>> Oh, I interpreted the timer check not as a PREEMPT_RT check, but a
>>>>> separate check for timers, which we must confirm are available before
>>>>> driving heavy machinery.
>>>>> So, if utsname.version contains "PREEMPT RT", then load the preempt-rt
>>>>> module. Once the module is loaded, from an init() function, run sanity
>>>>> checks, including the clock_getres check above. Is that about right?
>>>>
>>>> Yes. Sounds good to me.
>>>>
>>> Note we added a patch, called sysfs-realtime-entry.patch, but I'm not
>>> sure how far back it goes, at least it's in 3.x-rt kernels.
>>>
>>> This is the text from the patch
>>>
>>> "Add a /sys/kernel entry to indicate that the kernel is a
>>> realtime kernel.
>>
>> found this: https://bugzilla.redhat.com/show_bug.cgi?id=728551 and this:
>> https://github.com/clrkwllms/rt-linux/commit/274ca2cb72e013602cebb8dc142a7c69d42f92db
>>
>> looks like it is being used elsewhere: http://softballinfo.net/ret/root/usr/lib/python2.6/site-packages/sos/plugins/kernel_realtime.py
>>
>>>
>>> Clark says that he needs this for udev rules, udev needs to evaluate
>>> if its a PREEMPT_RT kernel a few thousand times and parsing uname
>>> output is too slow or so.
>>>
>>> Are there better solutions? Should it exist and return 0 on !-rt?"
>>>
>>> To use it, you do something like
>>> test -e /sys/kernel/realtime
>>
>> excellent - this works fine for me (I dont see us going back further than 3.4):
>>
>> mah@atom:~$ uname -a
>> Linux atom 3.4.13-rt-preempt-rt22+ #2 SMP PREEMPT RT Fri Oct 19 08:56:20 CEST 2012 i686 GNU/Linux
>>
>> mah@atom:~$ ls -l /sys/kernel/realtime
>> -r--r--r-- 1 root root 4096 2013-01-21 12:53 /sys/kernel/realtime
>>
>> mah@atom:~$ cat /sys/kernel/realtime
>> 1
>>
>> The way I read it the fingerprint is - '/sys/kernel/realtime' exists and contents is '1'
>>
>> thanks a lot!
>>
>
> No problem, now if you want to give back, please feel free to update
> the wiki as well!
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Runtime_detection_of_an_RT-PREEMPT_Kernel
- Michael--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
