Kernel hacker Ulrich Drepper has written a lengthy paper on the design and especially performance characteristics of memory of modern consumer hardware and it’s written for programmers. A great read so far (it’s published in parts by LWN):
What every programmer should know about memory by Ulrich Drepper.
In the wake of creating true async. IO in the linux kernel Ingo worked on so called syslets. A syslet is nothing more than one async system call to chain together a few arbitrary system calls. An example syslet would be:
1. Read from file descriptor 123
2. If 1 returned with error, break
3. Write which was read to file descriptor 321
4. If 3 succeeded jump to 1 otherwise break
This is represented by a few struct’s linked together of which the first is passed on to the kernel with the syslet system call. The systemcall returns practically directly and eventually the application can be notified (or can wait) on the syslet to complete. This could safe an enormous amount of system calls. This means way less context switches, which is very good for performance.
Syslets dawn, in a very primitive manner, kernelspace scripting. But hey, wasn’t kernelside scripting the thing that all linux dev’s dreaded? Wasn’t it Linus who joked that he would be in a mental institute whilst releasing Linux 3 with a VB message pump? Yes, they’re afraid of putting untrusted programs/scripts in kernelspace and they’ll barely acknowledge that syslets is the first step.
The problem with the current full-featured scripting languages is that they are, well, full-features gone wrong: they’re bloated and not really secure. In kernelspace you can’t allow any memory except for the scripts’ own to be accessed, not to mention the restrictions on resources and virtual memory won’t help you there. Most scripting languages weren’t developed with these restrictions in mind. Most languages have got evil functions in dark corners of the standard library that will allow you to do really evil stuff with memory.
As far as I know only .net (thus mono) have got a quite rigorous trust framework build in. .Net is bloated and proprietary and Mono is still (and probably will never be) feature complete though still being very bloated.
A very simple safe language is what we need, of which a compiler daemon is running as a system service, with which untrusted userspace programs can have scripts running in the kernel. I’m tempted to use one of the brainf*ck JIT’s, they’re small enough to thoroughly review :).
A kernelspace interpreter would do to, though, as a PoC.
Big fat warning, when hibernating using suspend2 it seems to corrupt some memory here and there. So don’t hibernate.
I found this patch: reiser4-for-2.6.19.patch.gz.
Try this patch:
http://vipernicus.evolution-mission.org/…
bcmap is a simply program to be linked against klibc to map Broadcom RAIDCORE disks to more sensible and stable device nodes.
Currently the bcraid drivers assign the next available sd node to a detected disk, which is very inconvenient when you have a usb stick inserted on boot which pushes your root disk from sda to sdb.
bcmap ensures that your first array will always be /dev/bca, which is a nice thing.
>>> bcmap-0.1.tar.bz2 (source code)
Licensed under the (holy) GNU GPL v.2
Here’s a small patch that tweak the broadcom raid drivers for the bc4000 series to run on the latest kernels:
http://w-nz.com/~darkshines/projects/bcraid-2.1.0-bw1.patch
Note that it is everything but complete. Some other pointers getting the bcraid to work:
CONFIG_SPARSEMEM=y)CONFIG_MAGIC_SYSRQ=y)At the moment I’m trying to get the bcraid module working in an initrd to allow the root partition on the raid drivers.