Kernel compilation and pesky mouse -2
This post attempts to chronicle the adventures in getting kernel 2.6.38 downloaded, compiled for self
First up though, is one more news item which I somehow overlooked and it did not get in the FOSS news post. This is about a recent conference which happened around the video4linux (v4l) . I share about this because it seemed interesting that 2-3 big companies both with GPL and companies which do not have any history of working with free software. As can be seen Samsung, Nokia and Cisco, Sony Ericsson are all interested in using the work. I know/knew that video is something that is always going to be interesting especially with the idea of all and any mobile devices being able to capture video in some nice, lossy or better lossless compressed format and uploaded somewhere to share but not to this extent. This is good to know.
Anyways back to things. As I’m sure people are aware, I had posted a post on kernel compilation around a month back. While everything is/was well and good upstream kernel work never stops (unless its Christmas or whenever Linus and other kernel developers decide to take a break). From what I have seen so far, we do get a new kernel release between 2 to 3 months and mostly somewhere there in-between. For me while the 2.6.37 was good I was slightly disturbed in the back of head because it was an odd version which I know is used for development versions, they are supposed to be a bit more radical than the even versions with new features and all. It’s usually the even versions which are supposed to be used for production purposes. I tried the old way of doing things but it was not to be :-
/linux/linux-2.6$ git checkout -b newkernel v2.6.38
error: You have local changes to 'drivers/input/mouse/psmouse-base.c';
cannot switch branches.
It is absolutely correct, as one remembers I have a troubling mouse (which I have to confess I love as it has been with me for so long) and don’t really want to give up just yet.
I asked Jim for the same and came to know of some commands as well.
~/linux/linux-2.6$ make localmodconfig
using config: '.config'
* Restart config...
* File systems
Second extended fs support (EXT2_FS) [N/m/y/?] n
Ext3 journalling file system support (EXT3_FS) [N/m/y/?] n
The Extended 4 (ext4) filesystem (EXT4_FS) [M/n/y/?] m
Use ext4 for ext2/ext3 file systems (EXT4_USE_FOR_EXT23) [Y/n/?] (NEW) Y
Ext4 extended attributes (EXT4_FS_XATTR) [Y/n/?] y
Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [Y/n/?] y
Ext4 Security Labels (EXT4_FS_SECURITY) [Y/n/?] y
EXT4 debugging support (EXT4_DEBUG) [N/y/?] n
JBD2 (ext4) debugging support (JBD2_DEBUG) [N/y/?] n
Reiserfs support (REISERFS_FS) [N/m/y/?] n
JFS filesystem support (JFS_FS) [N/m/y/?] n
XFS filesystem support (XFS_FS) [N/m/y/?] n
GFS2 file system support (GFS2_FS) [M/n/y/?] m
GFS2 DLM locking (GFS2_FS_LOCKING_DLM) [Y/n/?] y
OCFS2 file system support (OCFS2_FS) [M/n/y/?] m
O2CB Kernelspace Clustering (OCFS2_FS_O2CB) [N/m/?] n
OCFS2 Userspace Clustering (OCFS2_FS_USERSPACE_CLUSTER) [N/m/?] n
OCFS2 statistics (OCFS2_FS_STATS) [Y/n/?] y
OCFS2 logging support (OCFS2_DEBUG_MASKLOG) [Y/n/?] y
OCFS2 expensive checks (OCFS2_DEBUG_FS) [N/y/?] n
Btrfs filesystem (EXPERIMENTAL) Unstable disk format (BTRFS_FS) [N/m/y/?] n
NILFS2 file system support (EXPERIMENTAL) (NILFS2_FS) [N/m/y/?] n
Dnotify support (DNOTIFY) [Y/n/?] y
Inotify support for userspace (INOTIFY_USER) [Y/n/?] y
Filesystem wide access notification (FANOTIFY) [N/y/?] n
Quota support (QUOTA) [Y/?] y
Report quota messages through netlink interface
(QUOTA_NETLINK_INTERFACE) [Y/n/?] y
Print quota warnings to console (OBSOLETE) (PRINT_QUOTA_WARNING) [Y/n/?] y
Additional quota sanity checks (QUOTA_DEBUG) [N/y/?] n
Old quota format support (QFMT_V1) [N/m/y/?] n
Quota format vfsv0 and vfsv1 support (QFMT_V2) [N/m/y/?] n
Kernel automounter version 4 support (also supports v3) (AUTOFS4_FS) [N/m/y/?] n
FUSE (Filesystem in Userspace) support (FUSE_FS) [M/n/y/?] m
Character device in Userspace support (CUSE) [N/m/?] n
# configuration written to .config
Apparently, what the above command does is take the .config file that you have and see what works and doesn’t and does some magic (probably some intelligent algorithm being used) and it figures out the things you use and doesn’t and takes out all the hard work of figuring out kernel options you don’t use. It kinda updates the .config file. For the life of me though, I do not understand why it made GFS2 and OCFS2 file system support . I have no idea about these two file systems apart from the fact that the .config says about them.
The next step was actually adding a new remote (in svn speak, kinda like a new branch) so we do :-
$ git remote add 2.6.38.stable
This is just adding the new remote/branch. Apparently, it seems that upstream they make stable remotes as well (separate branches for the stable kernel versions). So for instance I could still go with this branch when the new shiny 2.6.39. comes out. I’m sure there would be a 22.214.171.124 and 126.96.36.199 coming out in the next weeks/months. I do know that the kernel team usually has 2-3 kernels which they also maintain for sometime. The updates in this would not be features but mostly bug-fixes.
$ git fetch 2.6.38.stable
remote: Counting objects: 1098, done.
remote: Compressing objects: 100% (184/184), done.
remote: Total 858 (delta 702), reused 825 (delta 671)
Receiving objects: 100% (858/858), 189.71 KiB | 70 KiB/s, done.
Resolving deltas: 100% (702/702), completed with 236 local objects.
* [new branch] master -> 2.6.38.stable/master
* [new tag] v188.8.131.52 -> v184.108.40.206
* [new tag] v220.127.116.11 -> v18.104.22.168
Now as we have given some name to the branch (in our case 2.6.38) now we can fetch it. It just fetches the new latest stable version of the kernel from the 2.6.38 series. As can be seen that is 22.214.171.124 as of the date I last did.
$ git reset --hard v126.96.36.199
Checking out files: 100% (9200/9200), done.
HEAD is now at cf6013b Linux 188.8.131.52
umm… nothing much to see just telling that the head is now 184.108.40.206 so all old kernels and their history is kinda wiped out. Basically cleaning stuff.
$ patch -p1
patching file drivers/input/mouse/psmouse-base.c
patching file drivers/input/mouse/psmouse.h
patching Jim’s patch and no there is no new version till yet.
$ make menuconfig
# configuration written to .config
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
While doing this there were quite a few things you can do depending on your system. For instance I had used this kernel article from linux.com to do my optimizations before. There are quite a few optimizations one can do but frankly, I do not know enough to know which ones to try and which ones to leave. For e.g. it was interesting to know while playing around in the .config that the btfrs filesystem support is still experimental in the kernel. I would have thought it would have matured by now (after what 2 years or so being in the kernel) and/or more talked about it. I didn’t understand any of the big memory support options as well, something to look into.
Anyways after the above was done, the only step left was to do the couple of last steps .
$ make deb-pkg
scripts/kconfig/conf --silentoldconfig Kconfig
# configuration written to .config
dpkg-deb: building package `linux-headers-220.127.116.11+' in
dpkg-deb: building package `linux-firmware-image' in
dpkg-deb: building package `linux-libc-dev' in
dpkg-deb: building package `linux-image-18.104.22.168+' in
This is the only computational heavy work in the whole thing. The debian packaging takes time and on my humble 2.4 Dual core, 2 GB RAM without many optimizations to the .config it took around 40 odd minutes. Needless to say, waiting is a pain.
When the above is done, one should check out the .deb packages.
The only thing left is to install the kernel .deb files.
02:22:22shirish@deb-home:~/linux$ sudo dpkg -i *.deb
[sudo] password for shirish:
(Reading database ... 238940 files and directories currently installed.)
Unpacking linux-firmware-image (from
Selecting previously deselected package linux-headers-22.214.171.124+.
Unpacking linux-headers-126.96.36.199+ (from
Selecting previously deselected package linux-image-188.8.131.52+.
Unpacking linux-image-184.108.40.206+ (from
Preparing to replace linux-libc-dev 2.6.32-31 (using
Unpacking replacement linux-libc-dev ...
Setting up linux-firmware-image (220.127.116.11+-2) ...
Setting up linux-headers-18.104.22.168+ (22.214.171.124+-2) ...
Setting up linux-image-126.96.36.199+ (188.8.131.52+-2) ...
update-initramfs: Generating /boot/initrd.img-184.108.40.206+
Generating grub.cfg ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-220.127.116.11+
Found initrd image: /boot/initrd.img-18.104.22.168+
Found linux image: /boot/vmlinuz-2.6.37+
Found initrd image: /boot/initrd.img-2.6.37+
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Microsoft Windows XP Professional on /dev/sda1
Setting up linux-libc-dev (22.214.171.124+-2) ...
reboot, see the 126.96.36.199 entry in Grub2, choose that and get in the new kernel.
$ uname -a
Linux deb-home 188.8.131.52+ #2 SMP PREEMPT Thu Mar 31 02:11:47 IST 2011
Mummy, I got the new kernel😛
While doing the above, I was honestly more interested in finding out if Jim had any luck getting his improvised driver in the mainline kernel so people with broken mice can still install any modern GNU/Linux OS and not think it’s the OS at fault but their hardware. This is what he had to say about that.
The stuff left to do on the patch is to make sure it’s not interfering with mouse operation for other mouse models, the code that decides which of the routines in drivers/input/mouse will run for any particular mouse is not easy for me to follow, and I want to make my next submission a shoo-in so it’ll take me time.
It’s that the same basic code is used for lots
and lots of mouse models, not all of them speak exactly the same language. Getting it wrong enough would mean people with those other models suddenly have broken mice.
– Jim Hill.
For the record, I would like to see his work integrated in the mainline kernel. If nothing else, it would be at least mean similar behavior to the reference OS as far as broken mouse’s go.