kernel recovery
gnome-kernel-manager 0.0.1
gnome-kernel-manager is a tool for managing kernel modules and more. more>>
gnome-kernel-manager is a gui for managing the kernel modules, .... Only Linux kernel is supported.
Main features:
- Shows the list of loaded modules.
- Shows the list of all installed modules.
- Shows information about modules.
- Supports (un)loading modules.
xlike Kernel Patchset 0.20f
xlike Kernel Patchset is a patch collection for the Linux vanilla kernel. more>>
These include code from Kernel Mode Linux, Rule Set Based Access Control, Novell AppArmor, Openswan, grsecurity, Linux VServer, Ndiswrapper, web100, Nefilters, Suspend2, Speakup, Amiga Smart File System, Cdemu, SquashFS, fbsplash, QuadDSP, and more. It also contains many drivers and fixes.
Enhancements:
- This version was updated to patch against Linux 2.6.20.
- User Mode Linux with Linux-PHC, LinuxIMQ, Web100, WANPIPE, WRR, ReiserFS4, SquashFS, UnionFS, Bootsplash, and Kernel Color Output were added.
suser-jengelh Kernel Patchset 2.6.22.1-ccj51
suser-jengelh Kernel Patchset is a patch collection for the Linux kernel. more>>
Enhancements:
- New netfilter modules (xt_TRACE, xt_connlimit, xt_u32, xt_gateway, xt_TARPIT, xt_time) and tproxy4 have been added.
- A number of patches have been outsourced to standalone packages.
Linux Kernel Monitor 0.3 Alpha
Linux Kernel Monitor is a tool for monitoring and managing linuxs kernel. more>>
lkmonitor tries to offer detailed information of the characteristics of the system, as type of cpu, state of the memory or the file system registered in kernel.
lkmonitor is an open source project with information about the source code and software architecture to make easy the development of new characteristics.
Enhancements:
- IO information, kernel information, networking info, processes specific information, filesystems, modules, etc.
Kernel Version Monitor 0.5
Kernel Version Monitor is a Superkaramba theme that creates a widget displaying the current version information of the kernel. more>>
Kudos and thanks to Richard "Ricardo" Szlachta for his advice on refining the aesthetics of this theme.
This is my first Superkaramba theme and a work in progress. I would love to hear comments, opinions and suggestions in order to improve this theme.
Lanshield Watchdog Linux Kernel Patch 0.1
Lanshield Watchdog Linux Kernel Patch drives an onboard (97317VUL) watchdog which resets the device every ten minutes. more>>
Lanshield Watchdog Linux Kernel Patch is for the onboard(97317VUL) watchdog which resets the device every 10 minutes.
BOARD: PENT/CPCI-765/
it was really hard to find the necessary information...
if you want to know how it works look in the code !!
You can compile it as module(which makes no sense) or fixed in the kernel in the userspace you just write to file /dev/watchdog.
Kernel Mode Linux 2.4.35.1_001 (For Linux 2.4)
Kernel Mode Linux project is a technology which enables us to execute user programs in kernel mode. more>>
The benefit of executing user programs in kernel mode is that the user programs can access a kernel address space directly. So, for example, user programs can invoke system calls very fast because it is unnecessary to switch between a kernel mode and a user mode by using costly software interruptions or context switches. Unlike kernel modules, user programs are executed as ordinary processes (except for their privilege level), so scheduling and paging are performed as usual.
Although it seems dangerous to let user programs access a kernel directly, safety of the kernel can be ensured, for example, by static type checking, software fault isolation, and so forth. For proof of concept, we are developing a system which is based on the combination of Kernel Mode Linux and Typed Assembly Language, TAL.
Version restrictions:
- On IA-32, programs executed in kernel mode shouldnt modify their CS, DS, FS and SS registers.
- On AMD64, programs executed in kernel mode shouldnt modify their CS register.
Enhancements:
- This version was merged with the 2.4.35.1 Linux kernel.
POE::Kernel 0.3502
POE::Kernel is an event driven threaded application kernel in Perl. more>>
SYNOPSIS
POE comes with its own event loop, which is based on select() and written entirely in Perl. To use it, simply:
use POE;
POE can adapt itself to work with other event loops and I/O multiplex systems. Currently it adapts to Gtk, Tk, Event.pm, or IO::Poll when one of those modules is used before POE::Kernel.
use Gtk; # Or Tk, Event, or IO::Poll;
use POE;
or
use POE qw(Loop::Gtk);
or
use POE::Kernel { loop => "Gtk" };
use POE::Session;
Methods to manage the process global Kernel instance:
# Retrieve the kernels unique identifier.
$kernel_id = $kernel->ID;
# Run the event loop, only returning when it has no more sessions to
# dispatch events to. Supports two forms.
$poe_kernel->run();
POE::Kernel->run();
FIFO event methods:
# Post an event to an arbitrary session.
$kernel->post( $session, $event, @event_args );
# Post an event back to the current session.
$kernel->yield( $event, @event_args );
# Call an event handler synchronously. Bypasses POEs event queue
# and returns the handlers return value.
$handler_result = $kernel->call( $session, $event, @event_args );
Original alarm and delay methods:
# Post an event which will be delivered at a given Unix epoch time.
# This clears previous timed events with the same state name.
$kernel->alarm( $event, $epoch_time, @event_args );
# Post an additional alarm, leaving existing ones in the queue.
$kernel->alarm_add( $event, $epoch_time, @event_args );
# Post an event which will be delivered after a delay, specified in
# seconds hence. This clears previous timed events with the same
# name.
$kernel->delay( $event, $seconds, @event_args );
# Post an additional delay, leaving existing ones in the queue.
$kernel->delay_add( $event, $seconds, @event_args );
Kernel-Machine Library 0.1
Kernel-Machine Library is a C++ library to implement kernel machines. more>>
The Kernel-Machine Library draws heavily from features of modern C++ such as template meta-programming to achieve high performance while at the same time offering a comfortable interface.
It enables compile-time selection of specialised algorithms on the basis of data types: for example, the specific case of a SVM in combination with a linear kernel can be computed by a specialised efficient algorithm.
The Kernel-Machine Library has implementations for the following kernel machines and their cited algorithms:
- Support Vector Machine [1, 2, 3]
- Relevance Vector Machine [4]
- Kernel Recursive Least Squares [5]
- Adaptive Sparseness using Jeffreys Prior [6]
- Smooth Relevance Vector Machine [7]
Up till now, the focus has been on regression. The handling of classification and ranking problems is being added.
ext3 0.0.7a
ext3 is a journaling support for ext2fs. more>>
What is journaling?
It means you dont have to fsck after a crash. Basically.
What works?
Journaling to a journal file on the journaled filesystem
Automatic recover when the filesystem is remounted
All VFS operations (including quota) should be journaled
Add data updates are also journaled
What is left to be done?
Quota support for non-data-journaled filesystems.
Journaling to an off-filesystem device, eg. NVRam
Decent documentation!
A few internal cleanups: migrating the extra buffer_head fields to a separate jfs_buffer_info field in particular.
Enhancements:
- The major change in this release is a missing byte-endian conversion in the recovery code. This problem affects both the ext3 kernel recovery and the recovery code in e2fsck. Please upgrade to e2fsprogs-1.21-WIP-0601.tar.gz or later.
- The other significant change is a fix when running shared mmaped files on ext3 with more than one ext3 filesystem active: it was possible for ext3 to get confused about which filesystem was active if the VM tried to swap out a page on one filesystem while processing a filesystem update on the other filesystem.
- Pin the buffer heads backing an inode to a transaction when the transaction starts, to prevent the inode being flushed to disk before transaction commit.
- Add a debugging check to trap any attempts to run a nested transaction inside a transaction on a different filesystem.
- Fix an assertion failure that could occur after allocating an indirect block but failing to allocate a block beneath it due to disk full.
- Fix a bug which meant that writes larger than 4k were never being coalesced into a single transaction.
- Rename the confusingly-named "tid_ge" transaction-greater-than function to "tid_gt"
- Update the README to describe the new ext3 features of current e2fsprogs.
OpenVZ kernel 2.6.16-1.2111_FC5.026test012 (Fedora Core 5)
OpenVZ project is an Operating System-level server virtualization solution, built on Linux. more>>
VPSs are isolated, secure environments on a single physical server, enabling better server utilization and ensuring that applications do not conflict.
Each VPS performs and executes exactly like a stand-alone server; VPSs can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries, and configuration files. OpenVZ is a subset of Virtuozzo.
Enhancements:
- Updated to the latest FC5 kernel and the latest OpenVZ kernel (including the checkpointing/live migration feature).
Cache colouring task_struct and kernel stack 2.5.0-0.5
This helps cache-colours both task_struct and kernel stack using a slab allocator for task_struct and initial stack pointer jittering for kernel stack. more>>
Cache colouring task_struct and kernel stack 2.5.0-0.5 is really useful for it is designed to cache-colours both task_struct and kernel stack.
This patch cache-colours both task_struct and kernel stack using a slab allocator for task_struct and initial stack pointer jittering for kernel stack. An extra structure is defined for task_struct allocations as long as a new init task structure.
By using three stack color bits, eight colors will be used for initial stack frame pointer jittering that should be enough for most cache architectures. Care has to be taken in increasing too much STACK_COLOUR_BITS because this can lead to kernel stack overflows, e.g. a STACK_COLOUR_BITS set to 4 with a cache line size of 128 bytes like P4 will result in a maximum jitter of 2048 bytes by leaving only 6 Kb for the kernel stack.
<<lessKernel Mode Linux 2.6.19_001
Kernel Mode Linux is a technology which enables the execution of user programs in a kernel mode. more>>
The benefit of executing user programs in kernel mode is that the user programs can access a kernel address space directly. So, for example, user programs can invoke system calls very fast because it is unnecessary to switch between a kernel mode and a user mode by using costly software interruptions or context switches.
Unlike kernel modules, user programs are executed as ordinary processes (except for their privilege level), so scheduling and paging are performed as usual.
Although it seems dangerous to let user programs access a kernel directly, safety of the kernel can be ensured, for example, by static type checking, software fault isolation, and so forth.
For proof of concept, we are developing a system which is based on the combination of Kernel Mode Linux and Typed Assembly Language, TAL. (TAL can ensure safety of programs through its type checking and the type checking can be done at machine binary level.
Version restrictions:
- User processes executed in kernel mode should obey the following limitations. Otherwise, your system will be in an undefined state. In the worst-case scenario, your system will crash.
- On IA-32, programs executed in kernel mode shouldnt modify their CS, DS, FS and SS registers.
- On AMD64, programs executed in kernel mode shouldnt modify their CS register.
- In addition, on AMD64, IA-32 binaries cannot be executed in kernel mode.
Enhancements:
- This release has been merged with the 2.6.19 Linux kernel.
openMosix kernel-2.4.26
openMosix is a Linux kernel extension for single-system image clustering. more>>
Once you have installed openMosix, the nodes in the cluster start talking to one another and the cluster adapts itself to the workload.
Processes originating from any one node, if that node is too busy compared to others, can migrate to any other node. openMosix continuously attempts to optimize the resource allocation.
We achieve this with a kernel patch for Linux, creating a reliable, fast and cost-efficient SSI clustering platform that is linearly scalable and adaptive. With openMosix Auto Discovery, a new node can be added while the cluster is running and the cluster will automatically begin to use the new resources.
There is no need to program applications specifically for openMosix. Since all openMosix extensions are inside the kernel, every Linux application automatically and transparently benefits from the distributed computing concept of openMosix.
The cluster behaves much as does a Symmetric Multi-Processor, but this solution scales to well over a thousand nodes which can themselves be SMPs.
The openMosix Community is very active, contributing add-on applications and sharing helpful information with all users. The openMosix Add-Ons and Community page lists these shared applications. And, it is all GPLd.
Linux Kernel Spinlock Metering 1.4.11
Linux Kernel Spinlock Metering is a kernel patch that allows you to build an i386, ia64, Alpha, Sparc64, or mips64 kernel... more>>
Data displayed includes the number of lock attempts, per-spinlock per-caller, the number of those attempts that were immediately successful vs. those that required the attempting locker to wait for the current lock-holder to release; the mean and max hold-time, and the mean, max, and cumulative wait-time. Whenever possible, the locking caller and the spinlocks are identified by their symbolic names, not by their virtual addresses.
Various patch sets are available. Version 1.1.4 patches the 2.2.14 kernel and reflects a relatively old flavor of Lockmeter. Version 1.4.11 patches the 2.4.16, 2.4.17, 2.5.3, and 2.5.5 kernels, and the previous release v1.4.9 patches various other releases of the 2.4.x kernel. This version 1.4 supports i386, alpha, ia64, mips64, and sparc64. The most recent version 1.5 is available as a patch against the 2.4.18 and various 2.5.x kernels, and it additionally supports mips (32-bit mips). Each is approximately 22 KB in gziped size. (Patches against a few older kernel versions are also available in the old subdirectory.) After applying the appropriate patch, make oldconfig presents a new Kernel lock metering option in the Kernel hacking subsection -- although only if CONFIG_SMP (Symmetric multi-processing support) has been enabled. The spinlock metering code is compiled into the kernel only when this new option is turned on.
Compiling the spinlock metering code into the kernel does not materially affect the kernel size because the additional code is roughly compensated for by the shrinking effect of the normally in-line locking routines now becoming procedure calls. A metering-capable kernel (i.e., with the patch applied, but data collection turned off) is negligibly slower than a non-metering-capable kernel, though a metering-capable kernel does slow when the metering data collection is turned on using the lockstat command (typically 8% for a systime==25% workload). Care has been taken to minimize performance degradation, and further improvements are in progress.
The lockstat command must also be downloaded, compiled, and installed. lockstat is a privileged command that requires root access. It reads and writes to the node /proc/lockmeter to control the kernels metering as follows:
lockstat on enables the kernels metering data collection,
lockstat options displays the collected data, and
lockstat off disables the metering data collection.
Run lockstat with no arguments to see a verbose description of the command arguments and options.
When metering is enabled, count and time data is collected in malloced arrays that are private to each CPU, thereby avoiding costly cacheblock coherency operations that would otherwise be required if all CPUs updated the same count and time fields. The lockstat command accumulates and sorts the per-cpu data at display time.
Lockmetering attempts to provide both "cause" and "effect" information about spinlock usage. The "hold time" metering exposes which spinlocks are being held and for how long, identified by where they are held inside the kernel. The "wait-time" metering exposes the effects of these hold-times when multiple CPUs concurrently contend for the same lock.