Lennart said:

Binding something like this to TTYs is just backwards. No graphical
session has a TTY attached anymore. And there might be multiple TTYs
used in the same session.

I really wonder why logic like this should live in kernel space at all,
since a) the kernel has no real notion of a session, except audit and b)
this is policy and as soon as people have this kind of group then they
probably want other kind of autogrouping as well for the other
controllers, which hence means userspace is a better, and configurable
place for this.

To which Linus then replied:

Numbers talk, bullshit walks.

The numbers have been quoted. The clear interactive behavior has been seen.

And you’re just full of bullshit.

Come back when you have something working and with numbers and better
interactive performance. Until then, nobody cares.

So, Lennart replied with his something better, 4 lines of bash:

Here’s my super-complex patch btw, to achieve exactly the same thing
from userspace without involving any kernel or systemd patching and
kernel-side logic. Simply edit your own ~/.bashrc and add this to the end:

if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
fi
Then, as the superuser do this:

mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/user

Done. Same effect. However: not crazy.

Of course the debate raged on because Linus thinks it’s stupid to make people have to set this up in userspace, and Lennart disagrees. Despite all this, finally everyone is at least acknowledging these issues and looking into them! Excellent.

-c

In short, he had already implemented something like this in a 10 line patch to his BFS scheduler, but he dropped them because it introduced regressions.

Those following the development of the patches for interactivity at massive load, I have COMPLETELY DROPPED them as they introduce regressions at normal workloads, and I cannot under any circumstances approve changes to improve behaviour at ridiculous workloads which affect regular ones. I still see precisely zero point at optimising for absurd workloads. Proving how many un-niced jobs you can throw at your kernel compiles is not a measure of one’s prowess. It is just a mindless test.

He goes on to say:

Again, I can’t for the life of me see why you’d optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn’t normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.

Perhaps this patch really helps the existing CFS implementation, but it’s still lacking when compared to BFS. Maybe it is a step in the wrong direction, but perhaps some improvement like this is better than none at all? It might be the catalyst needed to improve the kernel further. I never could understand why we couldn’t have more than one CPU scheduler in the kernel (like we do for block I/O).

Anyway, this is all quite interesting!

-c

Ksplice is technology which can apply patches to the Linux kernel on the fly, without needing a reboot. Also see my interview with Waseem Daher, one of the founding members of the team.

hv (Microsoft Hyper-V) drivers. Over 200 patches make up the
massive cleanup effort needed to just get this code into a
semi-sane kernel coding style (someone owes me a bit bottle of
rum for that work!) Unfortunately the Microsoft developers
seem to have disappeared, and no one is answering my emails.
If they do not show back up to claim this driver soon, it will
be removed in the 2.6.33 release. So sad…

After all his work to get the patches in, Microsoft no longer gives a crap? Perhaps they did just do it because they were forced to after violating the GPL.

make menuconfig ARCH=i386
make -j2 ARCH=i386
make modules -j2 ARCH=i386
make modules_install ARCH=i386
make install ARCH=i386

Phew.. glad I have that written down somewhere!

The latest developer model, the Neo Freerunner GTA02, has been available for a few months now and Jason bought one (which means I get to play with it). Originally the moko was developed using GTK, but now there are lots of different images for it.

Recently, Qt Extended (formally Qt Embedded pre Nokia purchase of Trolltech) released an image for the moko based on their 4.4.1 codebase. I thought I’d check it out and I was pretty impressed!

Note, that if you’re following this, make sure you get the correct version for your moko. The Freerunner is GTA02, while the original Neo1973 is GTA01.

First I had to download the kernel image and the root image (for the GTA02, of course).

The wiki has a good article on how to flash the moko. Essentially we use a program called dfu-util, which I had to run under a 32bit chroot as it seems to do weird things in 64bit.

From here, it’s pretty simple!

Step 1
Boot your moko to the uBoot menu, in preparation for flashing. To do this, make sure the moko is off, then hold down the option button on the top left while pressing the power button. You should see the uBoot menu.

Step 2
Plug the moko into the computer via the provided USB cable, in preparation to flash the unit.

Run the flashing utility to make sure you can see the device
./dfu-util -l
Found Runtime: [0x1d50:0x5119] devnum=10, cfg=0, intf=2, alt=0, name="USB Device Firmware Upgrade"

If you can see your device, then you’re ready to begin! Flash the kernel and then flash the root system
./dfu-util -a kernel -R -D Desktop/uImage-gta02-g291a9d50_mwester-stable.bin && ./dfu-util -a rootfs -R -D qtextended-4.4.1-gta02-rootfs-release-10022309.jffs2


Wait 15 min while the USB 1.1 interface transfers the files (slowly) and the unit is flashed.

Step 3
Boot the unit

The default interface is a dark colour, but Jason wanted something lighter. We changed the theme to one called ‘Smart’ – I assure you I had no influence over that decision!

Time for some screenshots..

The front screen after boot	The main menu
The settings menu	Making a call

There’s a handy little application called ‘screenshot’, which I used to take these

The front screen again	The main menu	The applications menu, where I’m scrolling it with my finger like on an iPhone..

The phone is a fantastic toy for the hacker but it’s definitely not ready for the consumer market, just yet. If you want a phone that’s fun to play with and are happy to hack around, then the moko is a great option. Apart from the stability of the software, the only main drawback is poor battery life (lasting about a day), but I’m sure this will improve with newer kernels.

Now, if only we could get Arjan’s 5 second boot working on the moko..

Of particular interest to me is using kexec as a way to suspend the machine, although it is only 32bit at the moment
There are plenty of other neat new features.