Thanks to the Anonymous Coward you bought me the last item on my wishlist at Amazon. It's now empty!I never thought that people would think highly enough of my work to shower me with that many presents :) A big thanks to all of you :)Now I'm left with the onerous task of finding more items for the wishlist 8)EDIT: I've added some new stuff - I like Wii games ;)
Go wild!Remember, this breaks the ABI with baelayout-2/openrc-0.1A patch for splashutils can be [http://roy.marples.name/openrc/splash.patch found here
OK, so OpenRC finally made it's way into Gentoo portage. However, you should be aware that what IS in portage has some cruft /etc/init.d/functions.sh that presently doesn't work on shells other than bash and it has a broken modules init script.Basically, the git repo hosted by Gentoo which I use now has a Gentoo branch which is what the ebuilds in portage pull from. I hate finding out about this myself without being told. But anyway, it's done and there's not much I can do about it.So in summary, if you use the ebuilds in Gentoo portage, OpenRC may break in silly ways. I'm not saying that the master branch won't, but I can certainly fix it a lot faster. Also, you can be sure my code works fine with bmake/pmake/gmake and a posix compliant shell, whereas any code in the Gentoo branch will be done for gmake and bash without regard to anything else. Which is why I feel dirty - all my hard work being abused.
Well, since the initial OpenRC release, quite a few people where vocal on IRC bitching about it's use of reallocing a NULL terminated char** list with claims that it's slow and inefficient. So, I decided to take the test and rework OpenRC around the TAILQ macros as found in queue(3) for dealing with lists of strings - which it does a fair bit. After spending more time than I anticipated on this, here are the results on my slowest box measured by bash's time feature:
ubersparc ~ # time rc real 0m0.215s user 0m0.036s sys 0m0.179s ubersparc ~ # time /etc/init.d/local restart * Stopping local ... [ok] * Starting local ... [ok] real 0m0.331s user 0m0.086s sys 0m0.251s
ubersparc ~ # time rc real 0m0.204s user 0m0.042s sys 0m0.161s ubersparc ~ # time /etc/init.d/local restart * Stopping local ... [ok] * Starting local ... [ok] real 0m0.338s user 0m0.082s sys 0m0.262s
So we can see that rc itself is quite a bit faster than before, as it did the bulk of string processing. However, services themselves are slightly slower. Why is this? Well, to keep the code similar we have to malloc and return a list head even if the list is empty. valgrind shows this as well, rc has less mallocs, whereas the services have more. So to improve the code futher we need to stop blindly mallocing list heads. It's hard to time overall speed, and my sparc doesn't run bootchart so I'll see if I can make some on my laptop, but my gut feeling is that it's no faster or slower overall than before.
In other words, using linked lists is only beneficial when dealing with large quantities of data. OpenRC doesn't deal with large quantities of data and as such is slower for starting individual services. The main speedup is purely due to joining and sorting which is faster due to linked lists.
This code has now been committed to git and the ABI has been broken (obviously - duh). The only things that links to us at this time are splashutils and einit. Here's a patch to splashutils to make it work again. If I think it has no immediate benefit, why did I commit the code? Well, the answer is purely because it will scale a lot better so hosts with lots of services will see a better speed increase than my slow sparc with few services.
I've also re-factored the code to match the BSDs KNF coding style and ditched my own custom one. It was fairly similar, so its not much of a change - the benefit is that hopefully more people will enjoy it :)