CPU new features enabled in Linux kernel -

if cpu has new features, how linux kernel handle ? remembered, pae not need rebuild entire system , linux seems installing driver , things work.

say, if cpu provides more execution modes, need rebuild entire system?

if so, why pae not need rebuild while 1 may need?

the types of new features linux kernel support without rebuilding kernel depend on instruction set , nature of features. since x86 provides direct means save processor state (as indicating how state exists), features add application-level state used new kernel.

some isas provide software layer can independent of operating system; example, alpha had pal (privileged architecture library). such layer can abstract hardware operating system (somewhat how bios used), allowing operating system use software perform implementation-specific operations.

obviously without isa-specified interface, linux extended support use of module provide similar abstraction. because linux open source there less incentive provide such interface, though there might advantage having single system image multiple system specializations. in principle dynamic kernel patching provide broader range of extensions, though intended critical (security/reliability-oriented) updates. generally, if 1 changing hardware, 1 rebooting , can update software.

in order use such interface, subsystems affected need know @ time of kernel compilation. if abstracting new feature existing kernel requires large abstraction layer software, using new kernel make more sense. if supporting new feature requires frequent calls , forth between abstraction layer software , existing kernel, performance tend suffer. (linux monolithic-oriented in design philosophy — preferring performance on abstraction — requiring become hypervisor layer unlikely attractive if added complexity miniscule.)

without such abstraction layer, changes add state or otherwise require new privileged operations cannot added without changing kernel. in principle, new modes require privileged enabling of mode did not add new state (e.g., mode indicator uses reserved bit kernel writes read) and safe other applications have enabled (because context switch code not modified) supported relatively simple kernel module.

for example, kernel module used support entirely new instruction encoding indicated reserved bit in page table entry of pages of code using new encoding. since change limited specific pages, no special support needed core of kernel

because pae used different page table entry format, adding support required new kernel. however, non-pae-aware subsystems upgraded support pae through kernel modules long core kernel supported pae.

new unprivileged instructions not add state or generate new types of interrupts/exceptions (that enter privileged mode), not require kernel support used application software.

(i not programmer less operating system developer, not know if linux abstracts exception handling in such way kernel module add new exception handling code. in theory, isa define larger exception handler table, reserving unused entries support future exceptions, in case, allowing module add handling of new exception type might practical. of course, if core kernel allows arbitrary interrupt handlers changed module, such interrupt — include system calls — directed module's code , call core kernel functions handle unchanged aspects. allowing module hijack kernel in manner seems inadvisable.)