Navigation
User login
Sponsored By
ZOMG, here's why I wrote a new "libc" (and why "libc" is in quotes)
This particular question seems to have come up a lot lately, on IRC as well as other places. People wonder why oh why I would have started Curie. A lot of it is along the lines of "why didn't you use one of the glibc alternatives?" and "ZOMG THE WHEEL IS BEING REINVENTED AGAIN!?". I'll try to point out why not only was it not possible to use "an alternate libc", but also why the whole notion of that sort of question is both pointless and meaningless in this context. In a nutshell: Curie is NOT simply a clone of glibc, or any other libc for that matter!
At its very core, Curie is meant to be a library that faciliates input, output and some primitive form of green threading and s-expression parsing/generation. On the vast majority of platforms and architectures, it does so by actively using the host libc; be that glibc, uclibc, newlib, dietlibc, or whatever else came with the operating system. This was the first step of implementing Curie. The reason to implement this at all was that I/O in C is generally either tedious (check for errors after each call, lots of casting things around, half the time with helper functions, etc etc whatever), or error-prone (think of the vast amount of exploits based on the *printf() class of functions; if you can't remember any, do some research before reading on) and conceptually designed to work with files/fifos/etc in blocking mode. The first two obviously warrant a wrapper/convenience library, and the latter one is a sure killer for green threading (which proved to be far superious performance-wise for our purposes in the late stages of eINIT's development).
So in essence, Curie is really just a wrapper library around a regular libc. Care has been taken to avoid naming collisions between POSIX and curie, and if you give it a thorough look then Curie turns out to be kind of a cross between libevent, an s-expression I/O library and some convenience functions for launching programmes.
However, it was clear from the very start that Curie was only going to use a very minimal set of system calls. Since the other design goal of Kyuba, and thus Curie, was a small memory and disk footprint due to the primary target platform being embedded devices, it was obvious that it would be beneficial to just wrap those system calls up in a tiny bit of assembly and thus obsolete the libc. This part needs to be done for each and every target platform, but it's really quite a trivial task and completely optional. That's why there's no curie "port" for linux/x86 (yet): no need to, it works fine without the port (only the memory footprint is about half a megabyte bigger compared to linux/powerpc and linux/amd64), none of the dev team actualy HAS a properly set up x86 linux system and it's unlikely to be used in embedded, so why bother. (and, of course, x86 assembly makes me puke and wonder why the fuck a retarded, hack-/patchfest architecture like that ever got popular in the first place.)
In summary: Curie is just a wrapper library, like any other such library that at least half the open source projects on this planet write for themselves, designed in a way that makes it trivially easy to "detach" it from the "required" libc and wrapped up in a stand alone library in case it might save some other projects with similar goals the trouble of writing their own. If you're still thinking "why didn't he use uclibc/dietlibc/yourfavouritetinylibc?", then it's pretty obvious that you haven't figured out what Curie is, and what it's supposed to do. For that matter, the C library to use isn't a programme or programme developer's choice to begin with, it's a choice that the operating sytem vendor/distributor/user makes.
I'm personally waiting for
I'm personally waiting for the solid reasons why x86/x64 is so bad. Okay, its operators are not exactly orthogonal, but it comes with pretty good vectorization. There's a reason ARM/SPARC/Power/MIPS aren't used on desktops, although having a nice, elegant design. x86 does the job and does it well.
But thanks for the post, this has clarified the issues for me :)
oh, and keep on going. I, for one, am impatiently waiting for the great einit replacement.
I guess x86 just has the
I guess x86 just has the most momentum. X86 chips used to be the cheapest, and even though windows NT had ports to a good deal of other architectures, back then a lot of things were still DOS-based, which in turn meant that x86 dos emulation was mandatory. There's a number of reasons why x86 is a bad architecture. My personal favourite is the distinct lack of registers, requiring massive stack use, and the really awful sysv ABI (which is used by linux). Basically, you're left with under 4 usable registers and if your function takes more than two arguments you need to go through the stack to get at them, which can make x86 assembly terribly illegible.
amd64/x64 is fine actually, it might carry a lot of bloat from x86 but the ABIs are sane (you hardly need to touch the stack to get at the arguments) and you generally have a dozen or so registers to use. Still not terribly much compared to powerpc or the other riscs, but good enough. There are some arguments against both x86 and x64, like poor theoretical virtualisation potential, but most of those were somehow fixed one way or another with addons to the original design (which is a bit of a gripe for me too, but it's not that important).
Oh, and glad the post cleared up some things for ya, I hope it does so for others as well ;D.
I think when you take a
I think when you take a project such as this and then try to improve it, bring it up to date and ultimatly make it function the best way, I find it absolutly acceptable to re-evaluate what is available and improve upon it sometimes even write better code to allow the project to be a better sucess, not to mention others can benefit of such improvemnets.... Never mind the bitchin and continue with good work.
Post new comment