I guess my last post was just 2 weeks before when I started studying day and night for my DSP and Signals exams. Before then I was working a bunch on my most recent project for work, which has resulted in 2 main articles so far. Those are Gentoo for the TS72xx Single Board Computer (Full Distro), and Gentoo for the TS72xx (Old Toolchain). The first of the two links contains information on how to put the ARM EABI kernel and userland on your TS72xx board, for a 25 time speedup in floating point processing. The second link contains information on how to create a 'compatibility' toolchain for building software that is compatible with the existing programs and libraries on the board as it is shipped.
After I finish one small project for my company, I would like to write up some information on replacing glibc with uClibc, for added space savings.
Anyway, I just finished writing my two exams! I passed them both, although not by any means with outstanding grades. I suppose that has to do with several things: having less time to study than my classmates, having an actual engineering job (not some job as a lab assistant), moving from Germany to Canada the same week that the exams were being written, and just organizing things. So, needless to say, it has been a bit stressful.
In any event, I'm very happy to be back in Montréal! Erin and I have a new apartment too, with an excellent location right across the street from Parc LaFontaine. It's beautiful! Also, I can't begin to express how nice it is to see the sun again on a daily basis - Kiel gets nothing but cloud and rain in the winter. The snow is also a very welcome sight. I know that most of you in the area are pretty sick of snow, but believe me, if you had nothing but rain all winter, you would beg to have the piles of snow back, and you would be happy about it too!
Erin & I just came from the radiology department at St. Mary's hospital here in Montréal, and we got the 2nd round of ultrasounds for Julien. It was quite funny actually, I asked them if I could put the images on my USB memory stick instead of a CD and they said that was fine if I could figure it out (they have some custom made software which is a bit confusing). So I did it and showed them how to do it and they gave us the images free of charge! I'll put them up on something like Picassa soon enough.
Happy St. Patty's Day by the way! Dr. Shine, our obstetrician, is also from Ireland and I think that today he was pretty happy when we said happy St. Patrick's day to him too!
I also just figured out a problem I was having with linux-2.4.26 and glibc-2.3.2 trying to get the aforementioned compatibility toolchain working. The problem was quite simple - __NR_waitpid, which is a syscall constant, was being defined in the ARM/linux headers, but the function is actually unimplemented for the ARM and is replaced by wait4.
The effects of this bug were, for instance
- Bash saying "wait_for(
): Function not implemented - waitpid and popen not working, returning errno 83 (ENOSYS/Function not implemented)
The problem was easy to fix by simply removing the definition in include/asm-arm/unistd.h for __NR_waitpid. (see Gentoo bug 213690). It's not defined in the 2.6 kernel headers either, and I think it was probably put there by accident.
2 comments:
I posted a comment on the gentoo forums to try to get my patch accepted... why do I have to fight to get a fix implemented? I do not know
Hi Chris,
I don't really know who to message regarding a complaint on bugs.gentoo.org, but your moderator profile caught my eye because your from Hamilton. I'm from Stoney Creek :) I'm sort of griping here, because some idiot named Jakob Moc disregarded the patch that I submitted [1].
There's a major bug in the 2.4.26-r1 gentoo sources (well, the headers at least). I'm speaking particularly about the ARM architecture - it's very, very small and only obvious to people who actually use the ARM. I realize that linux-2.4 is no longer supported by Gentoo, but in my opinion, if it's in the portage tree, it should at least provide quasi functional software.
If you fetch =sys-kernel/linux-headers-2.4.26-r1, and unpack it, you'll notice that __NR_waitpid is defined in include/asm-arm/unistd.h . This list is what defines the system calls for the linux operating system and is pivotal for having a functional libc.
According to the release notes from Russel King[2], who is basically the father of the ARM / Linux project, waitpid is _NOT_ implemented in the arm-linux kernel. If you scroll further down in include/asm-arm/unistd.h, you'll notice that waitpid is a static inline function that acts as a wrapper for wait4. That is further proof that waitpid is _not_ implemented. Hence, __NR_waitpid should _NOT_ be defined in asm-arm/unistd.h . If you look at your own 2.6 linux sources, you will find that __NR_waitpid is also not defined there. This is no coincidence, and it is not defined for a reason. Glibc will break if compiled against the 2.4.26-r1 kernel headers as they are, resulting in ENOSYS (errno # 38 / Function not implemented) every time that waitpid or popen is called.
So, I would like to kindly request that you pass the information along to a 'higher up', have whomever incorporate my patch into 2.4.26-r2 or whatever, and request that Jakob receive a slap on the wrist.
Kindest regards,
Christopher Friedt
[1] http://bugs.gentoo.org/show_bug.cgi?id=213690
[2] http://www.arm.linux.org.uk/developer/release-2.4.0-test.php
n response to 'Chris', who asked me why I can't use the 2.6 kernel instead:
...
I would _love_ to use the 2.6 kernel, and have already in fact done a port of the ARM EABI to the boards in question (www.embeddedarm.com) for the 2.6.23 kernels with maverick-crunch using gentoo.
The big BUT comes from the manufacturers of the board. They and their customers have thousands of boards in production environments and their boards are still using linux-2.4.26, as well as some proprietary modules which will not load in the 2.6 kernel.
I proposed that portage be used for creating binary packages and they said sure. The gentoo-embedded people were quite happy to have another arm board useable with gentoo-embedded. There are a lot of clients who are _really_ excited to be able to use portage to make building software easier.
The point is, the 2.6 kernel is great for newer projects and projects that are willing to be experimental, but for older, critical applications there are many, many people who are still not ready to switch to 2.6. Consider how long it took Debian, or RedHat for that matter, to switch to the 2.6 kernel after the majority of the world had already switched?
In any event, it's a simple 1-line patch - have you even looked at it? Here it is:
#define __NR_close (__NR_SYSCALL_BASE+ 6)
-#define __NR_waitpid (__NR_SYSCALL_BASE+ 7)
+ /* waitpid would be 7 */
#define __NR_creat (__NR_SYSCALL_BASE+ 8)
This is what is in the current 2.6.23 'gentoo-sources' in the same file:
#define __NR_close (__NR_SYSCALL_BASE+ 6)
/* 7 was sys_waitpid */
#define __NR_creat (__NR_SYSCALL_BASE+ 8)
Are you seeing any similarities yet?
Using your own policy, circularly:
If you don't support the 2.4 kernel now, and this patch will not imply that you need to support the 2.4 kernel later, does it have any effect other than helping out the people that might find the patch useful?
Please tell me - why will this patch not be accepted ? All of the reasons that I've heard so far have been "why can't you use a newer kernel? ", but that isn't actually a reason.
Post a Comment