New system calls in the Linux kernel (part of my MSc thesis)

Debian cd image for ppc64 pSeries
Boots ok, can be installed, some things has to be done manually right now, like
installing bootloader and kernel. This is the Woody PPC CD with some modifications,
changed kernel and modules, and made bootable on pSeries systems.
Although the CD is Woody, I prefer using Sarge on these machines.
I encountered some problems with Woody, for example, libraries are outdated for some
special apps from IBM, some binaries exited with 'Illegal instruction', maybe
because of bad optimization or buggy compiler.
This is just the first cd, you need this to boot, for the remaining CDs the offical PPC CD images
will do, get them from the mirror closest to you.

Separate drivers exist for all the components, I just had to put it together,
and make it work. SAA7146+SAA7111 works like a charm with Michael Hunold's drivers:
http://www.gdv.uni-hannover.de/~hunold1/linux/saa7146/index.html
Driver for the Temic tuner is also ok since lots of other cards use it,
works perfectly with the tuner module (tuner type 5).
TDA8425 generally work with the tvaudio module, but some
modifications were necessary for correct operation.
The MXB card is very similar to this card, so I started to play around with the
mxb module, changed the init the sequence, tuner type, made some card specific
modifications, removed the audio chip related code, and written it for the TDA8425 (datasheet: TDA8425_CNV_2.pdf ).
For 2.4 kernels: first apply this kernel patch for 2.4.26 (tvaudio). Configure, compile and boot it.
Next, get the dvb-kernel source from the site mentioned above, and apply this patch against it. Then compile, load 'mirage' module, launch xawtv.
For 2.6 kernels: dvb-kernel modules are included in 2.6, so you only need to apply my patch,
and compile the kernel with the driver. Patch for 2.6.5 here: soon

I will continue this project for newer kernels soon :)

Video Filters for MPlayer

There's no need to introduce MPlayer, everybody knows MPlayer, but in case you don't, see
http://www.mplayerhq.hu/. I wrote some video filters
I needed for special reasons, they're the following:

invert : as you guessed it simply inverts the image. I've also written
an MMX optimized version, I made some performance tests but sadly it does not speed up the
process too much.

deblend : based on Karel Suhajda's excellent deblend logo removal filter
for VirtualDub. I only ported one of it's features, the most useful I think:
the 'dealphablend' filter; with this there're good chanches for removing
transparent logos (for example TV station logos) from videos. If the opacity of the logo is not too high it is
possible to restore nearly the original image. Here are some
sample pictures
showing what can this do for you. Or check the homepage of the original vdub filter:
http://neuron2.net/delogo132/delogo.html
. It's slow and that's no lie it needs some optimizations, and I
haven't ported the mask generator algorhytms yet, so you have to generate the alpha
and color masks in vdub, and convert them.

over : puts a static raw RGB image on the video at the given position, and on
given frames, also supports transparent background.

fill : very simple filter, fills the given region (rectangle) with the same color
on given frames.

Cricket

Cricket is an universal monitoring tool, more info can be found here:
http://cricket.sourceforge.net/.
I wrote sample configs and scripts for some specific devices, which can be used with cricket:

Monitor 3Com SuperStack switches
Basically this script is a modification of the original listInterfaces script,
just copy listSuperStack into cricket's util/ directory. Create a new dir in
the cricket config tree, put the Defaults file there, run the listSuperStack
script, and place the output into a file. I added some RMON OIDs, so cricket
will be able to monitor things other than the usual ifInOctets and
ifOutOctets: total packets, multicast packets, broadcast pkts, dropped pkts,
oversized/undersized pkts and pkts categorized by size.Note: these switches do _not_ have high capacity counters, so if you get
samples in every 5 minutes (cricket default), counters can overflow for gigabit
interfaces.
Download the scripts and the Defaults file and a sample config:
cricket_3com_superstack.tar.gz

Monitor apcupsd running on remote machine via HTTP
This is a bit more complicated. First you have to generate a parsed status file
periodically from apcupsd.status file on the machine with the ups attached,
cron will do this for us. Next make this file available via http. Third enter
the URL of this status file in the supplied cricket config on the machine running
cricket. It's that easy.
Download Defaults file and sample cron and cricket config:
cricket_apcupsd_remote.tar.gz

Monitor local lm_sensors and hddtemp
First you need to have lm_sensors and hddtemp up and running. Then most likely
you'll have to adjust the supplied data gathering script and the Defaults file
to satisfy your needs, because the sensor chips are different. Hddtemp should
be okay if it supports your disk, maybe you'll have some trouble with older disks.
And of course don't always trust sensors and hddtemp, it's not uncommon that they
return false values.
Download Defaults file and sample data-gathering script:
cricket_sensors_hddtemp.tar.gz

Monitor RTAS sensors on an IBM pSeries machine
If you have enabled 'RTAS in /proc' support in your kernel, you'll have access
to RTAS sensors data via the /proc/ppc64/rtas/sensors entry, it's in human readable
form, you can just "cat" it, so it's simple to monitor it with cricket. This one is adjusted
for the pSeries 640 7026-B80 model.
Download Defaults file and sample data-gathering script:
cricket_rtas_sensors.tar.gz