{"id":114,"date":"2014-10-04T01:19:02","date_gmt":"2014-10-04T01:19:02","guid":{"rendered":"http:\/\/blogs.gentoo.org\/blueness\/?p=114"},"modified":"2014-10-04T01:19:02","modified_gmt":"2014-10-04T01:19:02","slug":"lilblue-linux-release-20140925-adventures-beyond-the-land-of-posix","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/blueness\/2014\/10\/04\/lilblue-linux-release-20140925-adventures-beyond-the-land-of-posix\/","title":{"rendered":"Lilblue Linux: release 20140925. Adventures beyond the land of POSIX."},"content":{"rendered":"

It has been four months since my last major build and release of Lilblue Linux, <\/em>a pet project of mine [1].<\/em>\u00a0 The name is a bit pretentious, I admit, since Lilblue is not some other Linux distro.\u00a0 It is Gentoo, but Gentoo with a twist.\u00a0 It’s a fully featured amd64, hardened, XFCE4 desktop that uses uClibc instead of glibc as its standard C library.\u00a0 I use it on some of my workstations at the College and at home, like any other desktop, and I know other people that use it too, but the main reason for its existence is that I wanted to push uClibc to its limits and see where things break.\u00a0 Back in 2011, I got bored of working with the usual set of embedded packages.\u00a0 So, while my students where writing their exams in Modern OS, I entertained myself just adding more and more packages to a stage3-amd64-hardened system [2] until I had a decent desktop.\u00a0 After playing with it on and off, I finally polished it where I thought others might enjoy it too and started pushing out releases.\u00a0 Recently, I found out that the folks behind uselessd [3] used Lilblue as their testing ground. uselessd is another response to systemd [4], something like eudev [5], which I maintain, so the irony here is too much not to mention!\u00a0 But that’s another story …<\/p>\n

There was only one interesting issue about this release.\u00a0 Generally I try to keep all releases about the same.\u00a0 I’m not constantly updating the list of packages in @world.\u00a0 I did remove pulseaudio this time around because it never did work right and I don’t use it.\u00a0 I’ll fix it in the future, but not yet!\u00a0 Instead, I concentrated on a much more interesting problem with a new release of e2fsprogs [6].\u00a0\u00a0 The problem started when upstream’s commit 58229aaf removed a broken fallback syscall for fallocate64() on systems where the latter is unavailable [7].\u00a0 There was nothing wrong with this commit, in fact, it was the correct thing to do.\u00a0 e4defrag.c used to have the following code:<\/p>\n

#ifndef HAVE_FALLOCATE64\r\n#warning Using locally defined fallocate syscall interface.\r\n\r\n#ifndef __NR_fallocate\r\n#error Your kernel headers dont define __NR_fallocate\r\n#endif\r\n\r\n\/*\r\n * fallocate64() - Manipulate file space.\r\n *\r\n * @fd: defrag target file's descriptor.\r\n * @mode: process flag.\r\n * @offset: file offset.\r\n * @len: file size.\r\n *\/\r\nstatic int fallocate64(int fd, int mode, loff_t offset, loff_t len)\r\n{\r\n    return syscall(__NR_fallocate, fd, mode, offset, len);\r\n}\r\n#endif \/* ! HAVE_FALLOCATE *\/\r\n<\/pre>\n
The idea was that, if a configure test for fallocate64() failed because it isn’t available in your libc, but there is a system call for it in the kernel, then e4defrag would just make the syscall via your libc’s indirect syscall() function.\u00a0 Seems simple enough, except that how system calls are dispatched is architecture and ABI dependant and the above is broken on 32-bit systems [8].\u00a0 Of course, uClibc didn’t have fallocate() so e4defrag failed to build after that commit.\u00a0 To my surprise, musl does have fallocate() so this wasn’t a problem there, even though it is a Linux specific function and not in any standard.<\/p>\n
My first approach was to patch e2fsprogs to use posix_fallocate() which is supposed to be equivalent to fallocate() when invoked with mode = 0.\u00a0 e4defrag calls fallocate() in mode = 0, so this seemed like a simple fix.\u00a0 However, this was not acceptable to Ts’o since he was worried that some libc might implement posix_fallocate() by brute force writing 0’s.\u00a0 That could be horribly slow for large allocations!\u00a0 This wasn’t the case for uClibc’s implementation but that didn’t seem to make much difference upstream.\u00a0 Meh.<\/p>\n
Rather than fight e2fsprogs, I sat down and hacked fallocate() into uClibc.\u00a0 Since both fallocate() and posix_fallocate(), and their LFS counterparts fallocate64() and posix_fallocate64(), make the same syscall, it was sufficient to isolate that in an internal function which both could make use of.\u00a0 That, plus a test suite, and Bernhard was kind enough to commit it to master [10].\u00a0 Then a couple of backports, and uClibc’s 0.9.33 branch now has the fix as well.\u00a0 Because there hasn’t been a release of\u00a0 uClibc in about two years, I’m using the 0.9.33 branch HEAD for Lilblue, so the problem there was solved — I know its a little problematic, but it was either that or try to juggle dozens of patches.<\/p>\n
The only thing that remains is to backport those fixes to vapier’s patchset that he maintains for the uClibc ebuilds.\u00a0 Since my uClibc stage3’s don’t use the 0.9.33 branch head, but the stable tree ebuilds which use the vanilla 0.9.33.2 release plus Mike’s patchset, upgrading e2fsprogs is blocked for those stages.<\/p>\n
This whole process may seem like a real pita, but this is exactly the sort of issues I like uncovering and cleaning up.\u00a0 So far, the feedback on the latest release is good.\u00a0 If you want to play with Lilblue and you don’t have a free box, fire up VirtualBox or your emulator of choice and give it a try.\u00a0 You can download it from the experimental\/amd64\/uclibc off any mirror [11].<\/p>\n