* Detecting PREEMPT_RT @ 2013-01-20 0:13 John Morris 2013-01-20 1:43 ` Carsten Emde 0 siblings, 1 reply; 10+ messages in thread From: John Morris @ 2013-01-20 0:13 UTC (permalink / raw) To: linux-rt-users Hi list, I'm part of a project that recently added PREEMPT_RT support (as well as Xenomai) to LinuxCNC/EMC2. The next sub-project is a 'universal binary'. The LCNC real-time module will run some checks to determine what RT systems, if any, are available on the running kernel, and then load the appropriate RT support module. We wish to distinguish between PREEMPT_RT and non-RT kernels because LCNC must confirm that the kernel really does have realtime capabilities, if that's what the user expects, and print big warning messages if not. LCNC drives machines that weigh many tons and spins spindles at 24k RPM, so this is important! The RT PREEMPT HOWTO discusses checking the kernel here: https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Checking_the_Kernel One method is to use string matching against the kernel version, which I'm a bit suspicious of. An improvement, figure 7 suggests using string matching against the process list in search of kernel thread names matching '[softirq-foo]'. Figure 8 show how to check /proc/interrupts on older kernels, but 9 states this doesn't work for newer kernels, so this isn't an option. We haven't found /proc/config.gz in any vendor-provided PREEMPT_RT kernels, so that is not an option either. So, is string matching against the process list the best detection method, or is there something I've missed? John ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 0:13 Detecting PREEMPT_RT John Morris @ 2013-01-20 1:43 ` Carsten Emde 2013-01-20 15:52 ` Michael Haberler 0 siblings, 1 reply; 10+ messages in thread From: Carsten Emde @ 2013-01-20 1:43 UTC (permalink / raw) To: John Morris; +Cc: linux-rt-users John, > I'm part of a project that recently added PREEMPT_RT support (as well as > Xenomai) to LinuxCNC/EMC2. > > The next sub-project is a 'universal binary'. The LCNC real-time module > will run some checks to determine what RT systems, if any, are available > on the running kernel, and then load the appropriate RT support module. > > We wish to distinguish between PREEMPT_RT and non-RT kernels because > LCNC must confirm that the kernel really does have realtime > capabilities, if that's what the user expects, and print big warning > messages if not. LCNC drives machines that weigh many tons and spins > spindles at 24k RPM, so this is important! > > The RT PREEMPT HOWTO discusses checking the kernel here: > > https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Checking_the_Kernel > > One method is to use string matching against the kernel version, which > I'm a bit suspicious of. 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. 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); } Hope this helps, -Carsten. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 1:43 ` Carsten Emde @ 2013-01-20 15:52 ` Michael Haberler 2013-01-20 17:32 ` Carsten Emde 0 siblings, 1 reply; 10+ messages in thread From: Michael Haberler @ 2013-01-20 15:52 UTC (permalink / raw) To: Carsten Emde; +Cc: John Morris, linux-rt-users Hi Carsten Am 20.01.2013 um 02:43 schrieb Carsten Emde: > 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 - Michael ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 15:52 ` Michael Haberler @ 2013-01-20 17:32 ` Carsten Emde 2013-01-20 18:39 ` John Morris 0 siblings, 1 reply; 10+ messages in thread From: Carsten Emde @ 2013-01-20 17:32 UTC (permalink / raw) To: Michael Haberler; +Cc: John Morris, linux-rt-users Hi Michael, >> 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". -Carsten. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 17:32 ` Carsten Emde @ 2013-01-20 18:39 ` John Morris 2013-01-20 20:18 ` Carsten Emde 0 siblings, 1 reply; 10+ messages in thread From: John Morris @ 2013-01-20 18:39 UTC (permalink / raw) To: Carsten Emde; +Cc: Michael Haberler, linux-rt-users On 01/20/2013 11:32 AM, Carsten Emde wrote: > Hi Michael, > >>> 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? Thanks for the tips, Carsten! John ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 18:39 ` John Morris @ 2013-01-20 20:18 ` Carsten Emde 2013-01-21 11:36 ` John Kacur 0 siblings, 1 reply; 10+ messages in thread From: Carsten Emde @ 2013-01-20 20:18 UTC (permalink / raw) To: John Morris; +Cc: Michael Haberler, linux-rt-users 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. -Carsten. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-20 20:18 ` Carsten Emde @ 2013-01-21 11:36 ` John Kacur 2013-01-21 12:14 ` Michael Haberler 0 siblings, 1 reply; 10+ messages in thread From: John Kacur @ 2013-01-21 11:36 UTC (permalink / raw) To: Carsten Emde; +Cc: John Morris, Michael Haberler, linux-rt-users On Sun, Jan 20, 2013 at 9:18 PM, Carsten Emde <C.Emde@osadl.org> 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. 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 If you need it in an older kernel that doesn't have it, it should port trivially. Thanks ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-21 11:36 ` John Kacur @ 2013-01-21 12:14 ` Michael Haberler 2013-01-21 12:17 ` John Kacur 0 siblings, 1 reply; 10+ messages in thread From: Michael Haberler @ 2013-01-21 12:14 UTC (permalink / raw) To: John Kacur; +Cc: John Morris, linux-rt-users John, Am 21.01.2013 um 12:36 schrieb John Kacur: > On Sun, Jan 20, 2013 at 9:18 PM, Carsten Emde <C.Emde@osadl.org> 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! - Michael > > If you need it in an older kernel that doesn't have it, it should port > trivially. > > Thanks > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-21 12:14 ` Michael Haberler @ 2013-01-21 12:17 ` John Kacur 2013-01-22 10:47 ` Michael Haberler 0 siblings, 1 reply; 10+ messages in thread From: John Kacur @ 2013-01-21 12:17 UTC (permalink / raw) To: Michael Haberler; +Cc: John Morris, linux-rt-users On Mon, Jan 21, 2013 at 1:14 PM, Michael Haberler <mail17@mah.priv.at> 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@osadl.org> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Detecting PREEMPT_RT 2013-01-21 12:17 ` John Kacur @ 2013-01-22 10:47 ` Michael Haberler 0 siblings, 0 replies; 10+ messages in thread From: Michael Haberler @ 2013-01-22 10:47 UTC (permalink / raw) To: linux-rt-users Am 21.01.2013 um 13:17 schrieb John Kacur: > On Mon, Jan 21, 2013 at 1:14 PM, Michael Haberler <mail17@mah.priv.at> 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@osadl.org> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-01-22 10:47 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-20 0:13 Detecting PREEMPT_RT John Morris 2013-01-20 1:43 ` Carsten Emde 2013-01-20 15:52 ` Michael Haberler 2013-01-20 17:32 ` Carsten Emde 2013-01-20 18:39 ` John Morris 2013-01-20 20:18 ` Carsten Emde 2013-01-21 11:36 ` John Kacur 2013-01-21 12:14 ` Michael Haberler 2013-01-21 12:17 ` John Kacur 2013-01-22 10:47 ` Michael Haberler
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.