or&nbsp;for&nbsp;all&nbsp;pages&nbsp;(code,&nbsp;stack,&nbsp;data,&nbsp;shared&nbsp;memory,&nbsp;mapped&nbsp;files,&nbsp;<br />shared&nbsp;libraries)&nbsp;to&nbsp;which&nbsp;a&nbsp;process&nbsp;has&nbsp;access&nbsp;(mlockall()).&nbsp;This&nbsp;<br />allows&nbsp;to&nbsp;guarantee&nbsp;that&nbsp;for&nbsp;instance&nbsp;small&nbsp;time-critical&nbsp;daemons&nbsp;stay&nbsp;<br />in&nbsp;memory&nbsp;which&nbsp;can&nbsp;help&nbsp;to&nbsp;guarantee&nbsp;response&nbsp;time&nbsp;of&nbsp;these&nbsp;<br />processes.&nbsp;Under&nbsp;Linux,&nbsp;this&nbsp;(like&nbsp;many&nbsp;other&nbsp;real-time&nbsp;related&nbsp;<br />features)&nbsp;is&nbsp;only&nbsp;allowed&nbsp;for&nbsp;root&nbsp;processes&nbsp;in&nbsp;order&nbsp;to&nbsp;avoid&nbsp;abuse&nbsp;<br />of&nbsp;this&nbsp;feature&nbsp;by&nbsp;normal&nbsp;users&nbsp;in&nbsp;large&nbsp;time-sharing&nbsp;systems.&nbsp;<br />Another&nbsp;application&nbsp;of&nbsp;memory&nbsp;locking&nbsp;are&nbsp;cryptographic&nbsp;computer&nbsp;<br />security&nbsp;programs.&nbsp;Using&nbsp;mlock(),&nbsp;these&nbsp;systems&nbsp;can&nbsp;ensure&nbsp;that&nbsp;an&nbsp;<br />unencrypted&nbsp;secret&nbsp;key&nbsp;or&nbsp;a&nbsp;password&nbsp;which&nbsp;is&nbsp;temporarily&nbsp;stored&nbsp;in&nbsp;a&nbsp;<br />small&nbsp;user&nbsp;space&nbsp;array&nbsp;will&nbsp;never&nbsp;get&nbsp;in&nbsp;contact&nbsp;with&nbsp;the&nbsp;swap&nbsp;device,&nbsp;<br />where&nbsp;under&nbsp;rare&nbsp;circumstances,&nbsp;someone&nbsp;might&nbsp;find&nbsp;the&nbsp;secret&nbsp;bytes&nbsp;<br />even&nbsp;many&nbsp;months&nbsp;later.&nbsp;For&nbsp;these&nbsp;applications,&nbsp;it&nbsp;would&nbsp;be&nbsp;desirable&nbsp;<br />if&nbsp;Linux&nbsp;allowed&nbsp;even&nbsp;non-root&nbsp;processes&nbsp;a&nbsp;small&nbsp;number&nbsp;of&nbsp;mlock()ed&nbsp;<br />pages&nbsp;(e.g.&nbsp;up&nbsp;to&nbsp;four&nbsp;locked&nbsp;pages&nbsp;per&nbsp;non-root&nbsp;process&nbsp;should&nbsp;be&nbsp;<br />ok).&nbsp;<br />Implementation&nbsp;status:&nbsp;Linus&nbsp;has&nbsp;now&nbsp;added&nbsp;full&nbsp;POSIX.1b&nbsp;memory&nbsp;<br />locking&nbsp;support&nbsp;to&nbsp;Linux&nbsp;alpha&nbsp;test&nbsp;kernel&nbsp;version&nbsp;1.3.43.&nbsp;There&nbsp;exist&nbsp;<br />also&nbsp;libc&nbsp;support&nbsp;and&nbsp;manual&nbsp;pages.&nbsp;So&nbsp;you&nbsp;won't&nbsp;have&nbsp;to&nbsp;apply&nbsp;the&nbsp;<br />POSIX.4_locking&nbsp;patch&nbsp;from&nbsp;Ralf&nbsp;Haller&nbsp;&lt;<a href="mailto:hal@iitb.fhg.de>">hal@iitb.fhg.de></a>&nbsp;any&nbsp;more.&nbsp;<br />Synchronous&nbsp;I/O&nbsp;<br />---------------&nbsp;<br />Databases,&nbsp;e-mail&nbsp;systems,&nbsp;log&nbsp;daemons,&nbsp;etc.&nbsp;require&nbsp;to&nbsp;be&nbsp;sure&nbsp;that&nbsp;<br />the&nbsp;written&nbsp;piece&nbsp;of&nbsp;data&nbsp;has&nbsp;actually&nbsp;reached&nbsp;the&nbsp;harddisk,&nbsp;because&nbsp;<br />transaction&nbsp;protocols&nbsp;require&nbsp;that&nbsp;a&nbsp;system&nbsp;crash&nbsp;or&nbsp;power&nbsp;failure&nbsp;<br />after&nbsp;the&nbsp;write&nbsp;command&nbsp;can&nbsp;not&nbsp;harm&nbsp;the&nbsp;data&nbsp;any&nbsp;more.&nbsp;POSIX.1b&nbsp;<br />defines&nbsp;the&nbsp;fsync()&nbsp;and&nbsp;O_SYNC&nbsp;mechanisms&nbsp;which&nbsp;Linux&nbsp;1.2&nbsp;already&nbsp;has.&nbsp;<br />In&nbsp;addition,&nbsp;there&nbsp;is&nbsp;a&nbsp;very&nbsp;useful&nbsp;new&nbsp;function&nbsp;fdatasync()&nbsp;which&nbsp;<br />requires&nbsp;that&nbsp;the&nbsp;data&nbsp;block&nbsp;is&nbsp;flushed&nbsp;to&nbsp;disk,&nbsp;however&nbsp;which&nbsp;does&nbsp;<br />NOT&nbsp;require&nbsp;that&nbsp;the&nbsp;inode&nbsp;with&nbsp;the&nbsp;latest&nbsp;access/modification&nbsp;time&nbsp;is&nbsp;<br />also&nbsp;flushed&nbsp;each&nbsp;time.&nbsp;With&nbsp;fdatasync(),&nbsp;the&nbsp;inode&nbsp;has&nbsp;only&nbsp;to&nbsp;be&nbsp;<br />written&nbsp;in&nbsp;case&nbsp;the&nbsp;file&nbsp;length,&nbsp;file&nbsp;owner,&nbsp;or&nbsp;permission&nbsp;bits&nbsp;have&nbsp;<br />changed.&nbsp;In&nbsp;database&nbsp;applications&nbsp;with&nbsp;mostly&nbsp;constant&nbsp;file&nbsp;sizes,&nbsp;<br />where&nbsp;you&nbsp;sometimes&nbsp;require&nbsp;an&nbsp;fsync()&nbsp;after&nbsp;each&nbsp;few&nbsp;written&nbsp;blocks,&nbsp;<br />but&nbsp;where&nbsp;you&nbsp;don't&nbsp;care&nbsp;about&nbsp;whether&nbsp;the&nbsp;access&nbsp;times&nbsp;in&nbsp;the&nbsp;inodes&nbsp;<br />on&nbsp;the&nbsp;disc&nbsp;are&nbsp;always&nbsp;100%&nbsp;up-to-date,&nbsp;fdatasync()&nbsp;could&nbsp;easily&nbsp;<br />double&nbsp;(!)&nbsp;the&nbsp;performance&nbsp;of&nbsp;your&nbsp;system.&nbsp;<br />There&nbsp;is&nbsp;also&nbsp;an&nbsp;msync()&nbsp;function&nbsp;for&nbsp;flushing&nbsp;a&nbsp;range&nbsp;of&nbsp;pages&nbsp;from&nbsp;<br />memory&nbsp;mapped&nbsp;files&nbsp;to&nbsp;the&nbsp;disk.&nbsp;<br />Implementation&nbsp;status:&nbsp;fsync(),&nbsp;fdatasync(),&nbsp;msync(),&nbsp;and&nbsp;O_SYNC&nbsp;are&nbsp;<br />already&nbsp;available.&nbsp;O_DSYNC&nbsp;has&nbsp;not&nbsp;yet&nbsp;been&nbsp;implemented.&nbsp;However&nbsp;<br />fdatasync()&nbsp;in&nbsp;Linux&nbsp;1.3.55&nbsp;is&nbsp;currently&nbsp;only&nbsp;an&nbsp;alias&nbsp;for&nbsp;fsync()&nbsp;and&nbsp;<br />therefore&nbsp;not&nbsp;yet&nbsp;any&nbsp;more&nbsp;efficient&nbsp;than&nbsp;fsync().&nbsp;<br />Timers&nbsp;<br />------&nbsp;<br />-&nbsp;Instead&nbsp;of&nbsp;the&nbsp;old&nbsp;BSD&nbsp;style&nbsp;gettimeofday()/settimeofday()&nbsp;calls,&nbsp;<br />POSIX.1b&nbsp;defines&nbsp;clock_gettimer(),&nbsp;clock_settimer()&nbsp;and&nbsp;<br />clock_getres().&nbsp;They&nbsp;offer&nbsp;nanosecond&nbsp;resolution&nbsp;instead&nbsp;of&nbsp;<br />microseconds&nbsp;as&nbsp;with&nbsp;the&nbsp;old&nbsp;BSD&nbsp;calls&nbsp;(at&nbsp;least&nbsp;on&nbsp;Pentiums,&nbsp;a&nbsp;<br />timer&nbsp;resolution&nbsp;much&nbsp;than&nbsp;a&nbsp;microsecond&nbsp;is&nbsp;available).&nbsp;In&nbsp;<br />addition,&nbsp;you&nbsp;can&nbsp;query&nbsp;now&nbsp;the&nbsp;actual&nbsp;resolution&nbsp;of&nbsp;the&nbsp;timer&nbsp;<br />with&nbsp;clock_getres().&nbsp;<br />-&nbsp;A&nbsp;new&nbsp;function&nbsp;nanosleep()&nbsp;allows&nbsp;to&nbsp;sleep&nbsp;also&nbsp;for&nbsp;less&nbsp;than&nbsp;a&nbsp;<br />second&nbsp;(the&nbsp;old&nbsp;sleep()&nbsp;had&nbsp;only&nbsp;second&nbsp;resolution).&nbsp;In&nbsp;addition,&nbsp;<br />nanosleep&nbsp;won't&nbsp;interfere&nbsp;with&nbsp;SIGALRM&nbsp;and&nbsp;in&nbsp;case&nbsp;of&nbsp;EINTR,&nbsp;it&nbsp;<br />returns&nbsp;the&nbsp;time&nbsp;left,&nbsp;so&nbsp;you&nbsp;can&nbsp;easily&nbsp;continue&nbsp;in&nbsp;a&nbsp;while&nbsp;loop.&nbsp;<br />-&nbsp;POSIX.1b&nbsp;defines&nbsp;also&nbsp;itimers,&nbsp;however&nbsp;instead&nbsp;of&nbsp;what&nbsp;the&nbsp;<br />existing&nbsp;BSD&nbsp;itimers&nbsp;provide,&nbsp;you&nbsp;now&nbsp;can&nbsp;deal&nbsp;with&nbsp;several&nbsp;timers&nbsp;<br />(at&nbsp;least&nbsp;32&nbsp;per&nbsp;process)&nbsp;and&nbsp;you&nbsp;have&nbsp;again&nbsp;theoretically&nbsp;up&nbsp;to&nbsp;<br />one&nbsp;nanosecond&nbsp;resolution.&nbsp;The&nbsp;old&nbsp;itimer&nbsp;functions&nbsp;can&nbsp;still&nbsp;<br />easily&nbsp;be&nbsp;implemented&nbsp;in&nbsp;libc&nbsp;for&nbsp;compatibility&nbsp;reasons&nbsp;using&nbsp;new&nbsp;<br />POSIX-style&nbsp;itimer&nbsp;system&nbsp;calls.&nbsp;<br />Implementation&nbsp;status:&nbsp;The&nbsp;POSIX&nbsp;clock&nbsp;and&nbsp;itimers&nbsp;system&nbsp;calls&nbsp;have&nbsp;<br />not&nbsp;not&nbsp;yet&nbsp;been&nbsp;implemented,&nbsp;although&nbsp;much&nbsp;of&nbsp;the&nbsp;functionality&nbsp;is&nbsp;<br />already&nbsp;available&nbsp;in&nbsp;the&nbsp;form&nbsp;of&nbsp;the&nbsp;BSD&nbsp;timers&nbsp;and&nbsp;adding&nbsp;them&nbsp;should&nbsp;<br />be&nbsp;quite&nbsp;easy.&nbsp;Queued&nbsp;signals&nbsp;have&nbsp;to&nbsp;be&nbsp;implemented&nbsp;first&nbsp;for&nbsp;<br />itimers.&nbsp;Nanosleep()&nbsp;is&nbsp;already&nbsp;available&nbsp;in&nbsp;Linux,&nbsp;but&nbsp;at&nbsp;the&nbsp;moment&nbsp;<br />it&nbsp;supports&nbsp;only&nbsp;10&nbsp;ms&nbsp;resolution&nbsp;and&nbsp;it&nbsp;can&nbsp;optionally&nbsp;perform&nbsp;short&nbsp;<br />microsecond&nbsp;precision&nbsp;busy&nbsp;waits&nbsp;of&nbsp;up&nbsp;to&nbsp;2&nbsp;ms&nbsp;length.&nbsp;<br />Scheduling&nbsp;<br />----------&nbsp;<br />Linux&nbsp;1.2&nbsp;has&nbsp;so&nbsp;far&nbsp;been&nbsp;optimized&nbsp;a&nbsp;lot&nbsp;as&nbsp;a&nbsp;time&nbsp;sharing&nbsp;system,&nbsp;<br />where&nbsp;several&nbsp;people&nbsp;run&nbsp;application&nbsp;programs&nbsp;like&nbsp;editors,&nbsp;compilers,&nbsp;<br />debuggers,&nbsp;X&nbsp;window&nbsp;servers,&nbsp;networking&nbsp;daemons,&nbsp;etc.&nbsp;and&nbsp;do&nbsp;word&nbsp;<br />processing,&nbsp;software&nbsp;development,&nbsp;etc.&nbsp;<br />However&nbsp;there&nbsp;are&nbsp;a&nbsp;lot&nbsp;of&nbsp;applications&nbsp;for&nbsp;which&nbsp;Linux&nbsp;is&nbsp;currently&nbsp;<br />unusable&nbsp;and&nbsp;for&nbsp;which&nbsp;even&nbsp;die-hard&nbsp;Linux&nbsp;enthusiasts&nbsp;have&nbsp;to&nbsp;keep&nbsp;a&nbsp;<br />stand-alone&nbsp;DOS&nbsp;version&nbsp;on&nbsp;their&nbsp;disk.&nbsp;For&nbsp;&gt;90%&nbsp;of&nbsp;these&nbsp;applications,&nbsp;<br />the&nbsp;fact&nbsp;that&nbsp;Linux&nbsp;is&nbsp;incapable&nbsp;of&nbsp;guaranteeing&nbsp;the&nbsp;response&nbsp;time&nbsp;of&nbsp;<br />an&nbsp;application&nbsp;is&nbsp;the&nbsp;major&nbsp;problem.&nbsp;Software&nbsp;for&nbsp;controlling&nbsp;e.g.&nbsp;an&nbsp;<br />EPROM&nbsp;programmer,&nbsp;a&nbsp;robot&nbsp;arm,&nbsp;or&nbsp;an&nbsp;astronomical&nbsp;CCD&nbsp;camera&nbsp;is&nbsp;not&nbsp;<br />realizable&nbsp;under&nbsp;a&nbsp;classic&nbsp;Unix&nbsp;if&nbsp;there&nbsp;is&nbsp;no&nbsp;dedicated&nbsp;real-time&nbsp;<br />controller&nbsp;present&nbsp;in&nbsp;the&nbsp;controlled&nbsp;device.&nbsp;A&nbsp;lot&nbsp;of&nbsp;commercially&nbsp;<br />available&nbsp;hardware&nbsp;has&nbsp;been&nbsp;designed&nbsp;with&nbsp;the&nbsp;real-time&nbsp;&quot;capability&quot;&nbsp;<br />of&nbsp;DOS&nbsp;in&nbsp;mind&nbsp;and&nbsp;has&nbsp;no&nbsp;own&nbsp;microcontroller&nbsp;for&nbsp;time-critical&nbsp;<br />actions.&nbsp;<br />A&nbsp;real-world&nbsp;example:&nbsp;I&nbsp;have&nbsp;myself&nbsp;spent&nbsp;a&nbsp;long&nbsp;frustrating&nbsp;time&nbsp;of&nbsp;<br />trying&nbsp;to&nbsp;implement&nbsp;an&nbsp;interface&nbsp;to&nbsp;a&nbsp;pay-TV&nbsp;decoder&nbsp;for&nbsp;Linux&nbsp;(which&nbsp;<br />emulates&nbsp;a&nbsp;chip&nbsp;card&nbsp;and&nbsp;allows&nbsp;you&nbsp;to&nbsp;watch&nbsp;pay-TV&nbsp;for&nbsp;free&nbsp;:-).&nbsp;In&nbsp;<br />this&nbsp;application,&nbsp;you&nbsp;have&nbsp;to&nbsp;wait&nbsp;for&nbsp;an&nbsp;incoming&nbsp;byte&nbsp;on&nbsp;the&nbsp;serial&nbsp;<br />port,&nbsp;then&nbsp;you&nbsp;have&nbsp;to&nbsp;wait&nbsp;for&nbsp;around&nbsp;0.7&nbsp;to&nbsp;2&nbsp;ms&nbsp;(never&nbsp;shorter,&nbsp;<br />never&nbsp;longer,&nbsp;otherwise&nbsp;the&nbsp;TV&nbsp;decoder&nbsp;gets&nbsp;a&nbsp;timeout&nbsp;and&nbsp;stops!)&nbsp;<br />before&nbsp;returning&nbsp;an&nbsp;answer&nbsp;byte.&nbsp;It&nbsp;is&nbsp;virtually&nbsp;impossible&nbsp;to&nbsp;<br />implement&nbsp;a&nbsp;user&nbsp;process&nbsp;for&nbsp;this&nbsp;task&nbsp;under&nbsp;Linux&nbsp;1.2,&nbsp;while&nbsp;it&nbsp;is&nbsp;<br />trivial&nbsp;to&nbsp;do&nbsp;this&nbsp;under&nbsp;DOS.&nbsp;I&nbsp;am&nbsp;looking&nbsp;forward&nbsp;to&nbsp;the&nbsp;day&nbsp;when&nbsp;<br />Linux&nbsp;provides&nbsp;enough&nbsp;real-time&nbsp;support&nbsp;for&nbsp;this&nbsp;application&nbsp;so&nbsp;that&nbsp;I&nbsp;<br />can&nbsp;finally&nbsp;remove&nbsp;MS-DOS&nbsp;from&nbsp;my&nbsp;harddisk.&nbsp;<br />For&nbsp;these&nbsp;and&nbsp;similar&nbsp;real-time&nbsp;applications,&nbsp;POSIX.1b&nbsp;specifies&nbsp;three&nbsp;<br />different&nbsp;schedulers,&nbsp;each&nbsp;with&nbsp;static&nbsp;priorities:&nbsp;<br />SCHED_FIFO&nbsp;A&nbsp;preemptive,&nbsp;priority&nbsp;based&nbsp;scheduler.&nbsp;Each&nbsp;process&nbsp;<br />managed&nbsp;under&nbsp;this&nbsp;scheduling&nbsp;priority&nbsp;possesses&nbsp;the&nbsp;<br />CPU&nbsp;as&nbsp;long&nbsp;as&nbsp;(a)&nbsp;it&nbsp;does&nbsp;not&nbsp;block&nbsp;itself&nbsp;and&nbsp;(b)&nbsp;<br />there&nbsp;comes&nbsp;no&nbsp;interrupt&nbsp;which&nbsp;puts&nbsp;another&nbsp;process&nbsp;<br />into&nbsp;a&nbsp;higher&nbsp;priority&nbsp;wait&nbsp;queue.&nbsp;There&nbsp;exists&nbsp;a&nbsp;FIFO&nbsp;<br />queue&nbsp;for&nbsp;each&nbsp;priority&nbsp;level&nbsp;and&nbsp;every&nbsp;process&nbsp;which&nbsp;<br />gets&nbsp;runnable&nbsp;again&nbsp;is&nbsp;inserted&nbsp;into&nbsp;the&nbsp;queue&nbsp;behind&nbsp;<br />all&nbsp;other&nbsp;processes.&nbsp;This&nbsp;is&nbsp;the&nbsp;most&nbsp;popular&nbsp;<br />scheduler&nbsp;used&nbsp;in&nbsp;typical&nbsp;real-time&nbsp;operating&nbsp;<br />systems.&nbsp;Function&nbsp;sched_yield()&nbsp;allows&nbsp;the&nbsp;process&nbsp;to&nbsp;<br />go&nbsp;to&nbsp;the&nbsp;end&nbsp;of&nbsp;the&nbsp;FIFO&nbsp;queue&nbsp;without&nbsp;blocking.&nbsp;<br />SCHED_RR&nbsp;A&nbsp;preemptive,&nbsp;priority&nbsp;based&nbsp;round&nbsp;robin&nbsp;scheduling&nbsp;<br />strategy&nbsp;with&nbsp;quanta.&nbsp;It&nbsp;is&nbsp;a&nbsp;very&nbsp;similar&nbsp;to&nbsp;<br />SCHED_FIFO,&nbsp;however&nbsp;each&nbsp;process&nbsp;has&nbsp;a&nbsp;time&nbsp;quantum&nbsp;and&nbsp;<br />the&nbsp;process&nbsp;becomes&nbsp;preempted&nbsp;and&nbsp;is&nbsp;inserted&nbsp;at&nbsp;the&nbsp;<br />end&nbsp;of&nbsp;the&nbsp;FIFO&nbsp;for&nbsp;the&nbsp;same&nbsp;priority&nbsp;level&nbsp;if&nbsp;it&nbsp;<br />runs&nbsp;longer&nbsp;than&nbsp;the&nbsp;time&nbsp;quantum&nbsp;and&nbsp;other&nbsp;processes&nbsp;<br />of&nbsp;the&nbsp;same&nbsp;priority&nbsp;level&nbsp;are&nbsp;waiting&nbsp;in&nbsp;the&nbsp;queue.&nbsp;<br />Processes&nbsp;of&nbsp;lower&nbsp;priorities&nbsp;will&nbsp;like&nbsp;in&nbsp;SCHED_FIFO&nbsp;<br />never&nbsp;get&nbsp;the&nbsp;CPU&nbsp;as&nbsp;long&nbsp;as&nbsp;a&nbsp;higher&nbsp;level&nbsp;process&nbsp;<br />is&nbsp;in&nbsp;a&nbsp;ready&nbsp;queue&nbsp;and&nbsp;if&nbsp;a&nbsp;higher&nbsp;priority&nbsp;process&nbsp;<br />becomes&nbsp;ready&nbsp;to&nbsp;run,&nbsp;it&nbsp;also&nbsp;gets&nbsp;the&nbsp;CPU&nbsp;immediately.&nbsp;<br />SCHED_OTHER&nbsp;This&nbsp;is&nbsp;any&nbsp;implementation&nbsp;defined&nbsp;scheduler.&nbsp;Under&nbsp;<br />Linux&nbsp;it&nbsp;is&nbsp;the&nbsp;classic&nbsp;time-sharing&nbsp;scheduler&nbsp;with&nbsp;<br />&quot;nice&quot;&nbsp;values,&nbsp;etc.&nbsp;Under&nbsp;Linux,&nbsp;all&nbsp;SCHED_OTHER&nbsp;<br />processes&nbsp;share&nbsp;the&nbsp;common&nbsp;static&nbsp;priority&nbsp;value&nbsp;0.&nbsp;<br />For&nbsp;security&nbsp;reasons,&nbsp;only&nbsp;root&nbsp;processes&nbsp;should&nbsp;under&nbsp;Linux&nbsp;be&nbsp;<br />allowed&nbsp;to&nbsp;get&nbsp;any&nbsp;static&nbsp;priority&nbsp;higher&nbsp;than&nbsp;the&nbsp;one&nbsp;for&nbsp;<br />SCHED_OTHER,&nbsp;because&nbsp;if&nbsp;these&nbsp;real-time&nbsp;scheduling&nbsp;mechanisms&nbsp;are&nbsp;<br />abused,&nbsp;the&nbsp;whole&nbsp;system&nbsp;can&nbsp;be&nbsp;blocked.&nbsp;<br />If&nbsp;one&nbsp;is&nbsp;developing&nbsp;a&nbsp;real-time&nbsp;application,&nbsp;it&nbsp;is&nbsp;a&nbsp;very&nbsp;good&nbsp;idea&nbsp;<br />to&nbsp;have&nbsp;a&nbsp;shell&nbsp;with&nbsp;a&nbsp;higher&nbsp;static&nbsp;priority&nbsp;somewhere&nbsp;open&nbsp;in&nbsp;order&nbsp;<br />to&nbsp;be&nbsp;able&nbsp;to&nbsp;kill&nbsp;the&nbsp;tested&nbsp;application&nbsp;in&nbsp;case&nbsp;something&nbsp;goes&nbsp;<br />wrong.&nbsp;You&nbsp;should&nbsp;be&nbsp;aware,&nbsp;that&nbsp;if&nbsp;you&nbsp;use&nbsp;X11,&nbsp;not&nbsp;only&nbsp;the&nbsp;shell,&nbsp;<br />but&nbsp;also&nbsp;the&nbsp;X&nbsp;server,&nbsp;the&nbsp;window&nbsp;manager&nbsp;and&nbsp;xterm&nbsp;will&nbsp;require&nbsp;a&nbsp;<br />higher&nbsp;static&nbsp;priority&nbsp;in&nbsp;order&nbsp;to&nbsp;stop&nbsp;processes&nbsp;blocking&nbsp;the&nbsp;rest&nbsp;of&nbsp;<br />the&nbsp;system.&nbsp;Therefore,&nbsp;testing&nbsp;real-time&nbsp;software&nbsp;will&nbsp;usually&nbsp;better&nbsp;<br />be&nbsp;done&nbsp;on&nbsp;the&nbsp;console.&nbsp;<br />With&nbsp;this&nbsp;POSIX.1b&nbsp;functionality,&nbsp;it&nbsp;is&nbsp;possible&nbsp;to&nbsp;run&nbsp;real-time&nbsp;<br />software&nbsp;under&nbsp;Linux&nbsp;by&nbsp;giving&nbsp;it&nbsp;root&nbsp;permissions&nbsp;and&nbsp;assigning&nbsp;it&nbsp;a&nbsp;<br />SCHED_FIFO&nbsp;strategy&nbsp;and&nbsp;a&nbsp;higher&nbsp;static&nbsp;priority&nbsp;than&nbsp;all&nbsp;other&nbsp;<br />classic&nbsp;SCHED_OTHER&nbsp;Linux&nbsp;processes.&nbsp;In&nbsp;addition,&nbsp;typical&nbsp;real-time&nbsp;<br />application&nbsp;lock&nbsp;their&nbsp;pages&nbsp;with&nbsp;mlockall()&nbsp;into&nbsp;the&nbsp;memory&nbsp;in&nbsp;order&nbsp;<br />