Free kernel source software for linux

Open Source in Tab is an extension which opens the pages source file in a new tab.

Opens the pages source file in a new tab. Has a preference to either open source in a new tab or existing tab.

Kernelconfig is a program that performs the steps required to configure, build, and install the Linux kernel.

It also has the ability to check for a later version of the kernel source and download, configure, build, and install it.

Kernelconfig is a program that does the steps to configure, build and install a Linux Kernel. To compile the source, you need FreeBasic or another Basic compiler.

If somebody doesnt like the fact that this program was written in Basic, they are welcome to rewrite it in Perl, Bash, C, C++ or whatever language they like best. To compile the program,
type "fbc kernelconfig.bas" from the directory that you extracted the tarball to. If you run kernelconfig with no arguments, it will look for the Linux kernel source in "/usr/src/linux."

Alternatively, you could run kernelconfig followed by the path to the Linux source. For example if you have the Linux source in your home directory in the src/linux subdirectory, you could do kernelconfig $HOME/src/linux. If kernelconfig finds the Linux source, it will run "make config" or "make oldconfig" if old configuration is found, "make dep", and "make bzImage." If youre root, kernelconfig will install the modules, copy the kernel to "/vmlinuz"
and run "lilo."

If you use the "-update" command-line option, kernelconfig will check ftp.kernel.org for a later version of the kernel than youre running. If it finds a later version, it will download it,
extract it to /usr/src/linux and do the above steps to configure and compile the kernel. For example you could do "kernelconfig -update", or "kernelconfig $HOME/src/linux -update."

POE::Kernel is an event driven threaded application kernel in Perl.

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 );

This is a cpu throughput benchmark originally devised and used by Martin J. Bligh. It is designed to compare kernels on the same machine, or to compare hardware. To compare hardware you need to be running the same architecture machines (eg i386) and run kernbench on the same kernel source tree.
kernbench runs a kernel at various numbers of concurrent jobs: 1/2 number of cpus, optimal (default is 4xnumber of cpus) and maximal job count. Optionally it can also run single threaded. It then prints out a number of useful statistics for the average of each group of runs.
You need at least 2Gb of ram for this to be a true throughput benchmark or else you will get swapstorms.
Ideally it should be run in single user mode on a non-journalled filesystem. To compare results it should always be run in the same kernel tree.
Using:
You need a kernel tree (any will do) and the applications time and awk
installed. time is different to the builtin time used by BASH and has more
features desired for this benchmark.
Simply cd into the kernel tree directory and type
/path/to/kernbench
Options:
kernbench [-n runs] [-o jobs] [-s] [-H] [-O] [-M] [-h] [-v]
n : number of times to perform benchmark (default 5)
o : number of jobs for optimal run (default 4 * cpu)
s : perform single threaded runs (default dont)
H : dont perform half load runs (default do)
O : dont perform optimal load runs (default do)
M : dont perform maximal load runs (default do)
f : fast run
h : print this help
v : print version number
Enhancements:
- Incorrect counting of CPUs was fixed.
- The -j option was changed to at least 4GB ram.

Kernel Mode Linux project is a technology which enables us to execute user programs in kernel mode. In Kernel Mode Linux, user programs can be executed as user processes that have the privilege level of kernel mode.
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.

Install Kernel interfaces with the Linux operating system by running a series of functions or groups of commands that automate the compiling or recompiling and installation process.
Install Kernel project consists of three groups of functions: building the kernel and moving files, checking dependencies, and editing the boot loader configuration file. Grouping all of the functions in these three groups makes maintaining and altering the script much easier.
Install Kernel can also be considered a program, because a program does checking and makes choices accordingly. A script is usually a file, which contains a certain number of commands with no logic in mind. Therefore, while ik is technically a script, it can also be called a program.
Dependency checks are to make sure the current system configuration and settings are properly setup before proceeding with the kernel build. There are seven dependency checks, they are: a root check, space check, link check, boot check, boot loader check, configuration check, and a module check.
First, the root check makes sure the user is a super user; which means they are capable of editing important system files only accessible to the root account. The space check makes sure there is at least 200 megabytes available.
The kernel source these days is around 150 megabytes just for the source code. When one compiles the kernel, it may increase the size to 50 megabytes or more. Therefore, ik
checks for at least 200MB available in order to successfully compile the kernel without running out of space. Next, it is not required, but it is standard to have a symbolic link of /usr/src/linux pointing to /usr/src/linux-x.y.z.
The fourth check makes sure the user has a /boot directory, this is where the Linux kernel files will be installed to. The fifth check determines the bootloader that will be used. There are two main boot loaders in Linux. LILO and GRUB are the two most popular for booting the operating system.
This check accurately finds whether the kernel was booted from either LILO or GRUB by checking which bootloader was used last. It then tells the rest of the script to edit the correct one accordingly. The sixth configuration check is to make sure users have created a proper kernel configuration file, which is used in the process of building the Linux kernel.
The final check is a module check, if modules are turned off, the script will determine this and alter the installation process to install with no module support. The main idea behind the depdency checks is to make sure the user cannot damage his or her system if they do not do something right.
The installation process also contains seven functions. The installation process is usually several commands. However, because of the differences that can occur in a users configuration file, each part of the building process must be checked and the building process may need to be altered.
The first function makes sure the dependencies are setup correctly for all files in the kernel source tree. The second function deletes stale object files and or old kernel files. Next, the third function is the kernel build function; this function runs a command to build the Linux kernel. Next, functions four and five make and install modules if the user had specified module support in his or her kernel configuration file.
The sixth function moves the Linux kernel and its System dependency map to the boot partition. The last function of the build process sets up module dependencies for the new kernel if modules were defined. The installation process also includes a small error check for each part of the kernel build process.
If any part of the kernel build process fails; the script will abort, not modifying any boot loader configuration files. This is important; because if it did not abort, it may alter the boot loader configuration files, thus rendering the system unbootable. It is important to support every Linux configuration possible because of the wide use of this script.
The boot loader configuration and setup process is probably the most important aspect of installing a new kernel. An improper boot loader configuration may leave one with system that does not boot; or simply does not boot the new kernel.
It is also important, as some systems may have two or more boot loaders installed. There are four functions defined for this process. The first function uses the boot loader, which was defined during the configuration checks. The second function defines where the LILO or GRUB configuration files are located.
Next, depending on which boot loader is found, either LILO or GRUB configuration files are edited automatically by sed. Sed is a stream editor, which edits a file with no user intervention. If user intervention were required, the user would have to be present between certain parts of the kernel installation. With ik, it makes efficient use of a users time because only one command needs to be entered to complete the entire installation and setup process.
Install Kernel is a useful tool for those who are new to Linux, rebuild their kernel often, or value their time. It reduces the commands for installing the kernel from about thirteen to one. Users new to Linux may find this attractive.
This is because the entire process is automated; and if something is not correct, in most cases ik will notify the user what is incorrect, and how to fix the error. On the other side, for experienced users who do not wish to spend valuable time installing a new kernel, this is also very handy. Install Kernel is efficient by requiring no user intervention and reducing time spent on kernel installs, and effective by giving new to Linux the option for an easy kernel upgrade.
Enhancements:
- Updated to work with the newer version of coreutils for head and tail.
- The MAKE_JOBS directive has been removed in favor of make -j2 to prevent make from spawning hundreds of jobs if /proc/cpuinfo did not exist.

Kernel Version Monitor is a Superkaramba theme that creates a widget displaying the current version information of the Linux kernel as put forth by the kernel.org RSS feed here: http://kernel.org/kdist/rss.xml . Kernel Version Monitor uses the Tux icon from the nuoveXT icon theme found at http://nuovext.pwsp.net

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.

iRiver iFP is an user-space open-source driver for iRivers iFP flash portable MP3 players.
This project encourages open source driver development for iRivers iFP portable music players. Ifp-driver was started by Pavel Kriz with ifp-line, a command-line program and the first Free iFP driver. Today, the ifp-driver mailing list is a hub of discussion for iFP driver development: participants include everyone from authors of spin-off projects, to prospective owners/users.
Ifp-driver home projects:
ifp-line is the original command line utility and Midnight Commander plugin. Stable.
linux-filesystem a linux kernel module that mounts iFP devices as filesystems. Stable.
libifp a generic iFP support library. Stable.
Related projects:
user interfaces
ifpgui a kde/qt manager by Jim Campbell; uses libifp.
ifp-gnome a gnome manager by Billy Charlton; uses ifp-line.
ifp-manager a perl+gtk2 gui
giriver a python+gtk2 frontend; uses libiriver. (unmaintained)
plugins
kio_iriver KDE KIO slave by Joe Roback; uses libiriverdriver.
[unnamed] KDE KIO slave by Thomas Loeber.
libraries
libiriverdriver a C++ library driver by Joe Roback.
pyifp python bindings for libifp, by James Evans
rubyifp Ruby bindings for libifp, by Martin Schanzenbach
libifp-cil Mono/.NET bindings for libifp, by Christian Elkjaer
libiriver an older ifp library. (unmaintained)
Unless otherwise noted, projects support all iRiver iFP devices. Users have reported successfully accessing models iFP-1xx,3xx,5xx,7xx,8xx,9xx and N10. We dont anticipate difficulty supporting future models.
Enhancements:
- Release ifp-line-0.3.
- ifp.c: Change "ifp version" output for GPL compliance.
- NEWS: Fix Engrish in NEWS.
- README: Add notice for error with non-ASCII filename.
- ChangeLog: Add ChangeLog.