Hey

Just filing a bug to suggest three changes to Arch's kernel.

The first is the HZ value in use. 250 is not a happy compromise, and rather provides the worst of 100 and 1000, rather than the best. Some drivers are hard coded to 1000, so while using 250 has yet to cause obvious bugs for most of us, it may for some.

To give you a bit of an idea why not to run 250, this is the patch Con Kolivas, who has contributed a range of things to our linux kernel, includes in his CK patchset which he much more politely describes 250, than I've heard him describe it on IRC.
http://ck.kolivas.org/patches/2.6/2.6.14/2.6.14-ck7/patches/hz-no_default_250.patch

He recommends 100 or 1000 instead. 1000 would be the most appropriate option, its been used as the default for the whole 2.6 series. 100 was used for 2.4.

The second suggestion is the enabling of the HFS+ flesystem driver module, which people have been requesting for a while now, to use apple formatted ipods.

My last suggestion, is to upgrade the Arch kernel to use initramfs instead of initrd. An example of a mkinitramfs equivalent will be in the community repo soon, you can take a look at it in CVS now.
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/system/mkinitramfs/?cvsroot=AUR

Phrakture advises me that it would be better to use klibc instead of busybox, which I will do when he completes his initramfs script setup.

The advantage of initramfs, is that the / filesystem is NOT mounted by the kernel, it is mounted by the script within the initramfs. This means that you can have a nice small userspace in the initramfs and mount / whenever and however and as whatever you like. You could use fuse to mount / over SSH, or if you so much wanted to. A samba /, cifs /, any filesystem for /. It would simplify encrypted filesystems substantially, and you could even get it to ask a password before mounting.

The second advantage of initramfs, is that it is not restricted to a set size as initrd is. An initramfs is just a cpio (similar to tar) image, and can be of any reasonable size. If you take a look at my quick mkinitramfs script, it is substantially simpler.

And the third benefit of initramfs, is that to switch, there is no obvious change to the user. My mkinitramfs, so as to not eliminate the stable kernel, uses its own named config, but inside it, and to the user, that config is identical, as well as allowing extra things, such as custom DSDT support and fbsplash. A initramfs is installed in lilo and grub identical to an initrd. Ubuntu already uses initramfs, and I am sure other distros do too. Originally initramfs was going to be the next big thing, and supercede initrd when 2.6 came out, however it didnt mature quick enough, and people simply didnt realise it existed, so didnt move from initrd.

The next ArchCK release, will be using initramfs. I cannot use initrd for ArchCK, as fbsplash, and custom dsdt support are not supported by initrd.

iphitus