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!
John
--
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
