Roy's Blog

A Hacker's musings on Code | Tech | Life

Ever since baselayout-1.11 first came into being, I've never been totally happy with the internal API I've been using. Well, with the release of baselayout-1.12.0_pre11 I think I've finally cracked it. Each module is now around 800 - 1000 bytes smaller than the ones we've been using thus far. The only function we now require is modulename_depend() - all the others are now optional.

With -r1 which fixes a few critical bugs, I think we're finally stable across the board. The only issue to be resolved (which is just changing default settings) is #112088 which defines default timeouts for ifplugd/netplugd and wpa_supplicant. baselayout-pre_10-r1 changed the defaults to -1 means means "return instantly and mark inactive" instead of 10 which means "wait 10 seconds and mark started/stopped accordingly".

Personally, I like the -1 default which makes the most sense from a workstation/laptop perspective especially when you use udev/hotplug to start interfaces and don't have any interfaces aside from lo in your runlevels. Infact this whole issue seems to stem from having interfaces in a runlevel. We could alleviate this by making the default for RC_STRICT_NET_CHECKING="lo" which solves it another way, but could mess some server configs.

Not many people have complained so far, so we'll see how we go :)

Discuss this Post

Flanders fields the poppies blow Between the crosses, row on row That mark our place; and in the sky The larks, still bravely singing, fly Scarce heard amid the guns below. We are the Dead. Short days ago We lived, felt dawn, saw sunset glow, Loved and were loved, and now we lie In Flanders fields. Take up our quarrel with the foe: To you from failing hands we throw The torch; be yours to hold it high. If ye break faith with us who die We shall not sleep, though poppies grow In Flanders fields. - John McCrae I have no memory of [Wing Commander Roy Marples](http://www.rodneyb.demon.co.uk/WcdrRM.htm), but I have his name. I will never, ever forget what he did. He fought in the 2nd World War, and rememberance day is about the 1st World War. But war is war, 1st, 2nd ... 3rd? History teaches us one thing .... [we do not learn!](http://www.iraqbodycount.net/) And yet we must otherwise every sacrifice made is meaningless ....

Discuss this Post

So we added a whole bunch of new shiny features to baselayout of late, one of these included new parallel startup code which required a better service dependency and ordering function. New parallel was nice and fast :) , whereas the new dependency and ordering function was dawg slow bro :(After much head scratching, there wasn't too much more optimizing that we could do at the time. The trace_dependencies functions has been re-written a few times to solve bugs and try and make it faster. Well, today I've comitted a fix that cut's around 70% off the time it takes to run 8)We also think we've found the problem with a service ordering bug which I found out by luck on my server while testing the new code. Basically, a baselayout ebuild (not sure which one as they seem to work) or a stage3 tarball placed faulty symlinks in /etc/runlevels/{boot,default}. Now we know the solution (hopefully), we'll release a pre10 soon and maybe thing about making it stable?So if you're suffering from that bug, rc-status from baselayout-1.12.0_pre10 will tell you if you have any broken symlinks in your runlevels :)

Discuss this Post

OK, madwifi has been pissing me off. For quite some time, ever since I got the card really. The madwifi-driver ebuild at first was good and reliable. But for a while the quality has been degrading somewhat, especially as wpa_supplicant now requries specific madwifi headers. And the latest batch in portage isn't exactly compatible. I also downloaded a CVS snapshop and tried that out. Oh dear, bad mojo! They now require you to run a special tool to create a friggin wireless interface! What happend to hotplug? For example, I fully expect to insert a card, load the driver and there's the wireless interface waiting to be configured. But no, I have to tell it what sort of interface I want. Phooey! :(So the quest for something new! At first I wanted an Intel chipset based card, but 10 mins research shows they are laptop only - sucks! Then I find that RaLink rt2x00 cards have native linux drivers with no firmware required and they get full use of the kernel as the drivers are pure GPL. So I placed the order and got to work on an ebuild for the rt2x00 beta driver which is a new all singing all dancing driver for all rt2x00 chipsets. RaLink open-sourced all their drivers (rt2400, rt2500, and a USB one) and the new rt2x00 driver is a rewrite combining all three + the generic ieee80211 stack.Today I got my hardware - a pci and a pcmcia card. All working fine from my new ebuild.OK, there are a few caveats - SMP is broken, 4K stacks can't be enabled and low latency pre-emptive kernel don't work either (all I can live without). But the beta driver works. 8) It has a few issues, the most important one being the connectivity isn't quite there (it drops from time to time, but comes back automatically) and wpa_supplicant support is broken.I'm confident that this driver will shape up to be something good, it's already better than the prism54 driver and provided that they never go down the "need to use our tools" road like madwifi they'll do well :) Go and try it out!

Discuss this Post

After yesterdays blog, g2boojum asked if it would be faster to actually use the tsort C binary if available. My response was that I would expect it to be faster, but not by much as most of the work is making the dependancy tree to start with. Being the silly sort I am I decided to back myself up with benchmarks! :)

C tsort stopping

real 0m0.343s
user 0m0.196s
sys 0m0.144s

C tsort starting

real 0m0.243s
user 0m0.132s
sys 0m.112s

bash tsort stopping

real 0m0.353s
user 0m0.248s
sys 0m0.108s

bash tsort starting

real 0m0.239s
user 0m0.164s
sys 0m0.076s

So there we have it! But what does this mean? Why is C tsort faster at stopping than bash? Why is bash tsort faster at starting than C? More importantly does this so that I'm a really good coder? :evil:

This is easily explained - when we "stop" we load all modules available. When we start we filter out duplicates based on user and then system preference, which means we're dealing with less modules. My bash code is more efficient, purely because I don't have to rebuild the entire PROVIDES array at the end of the sort as it gets changed during the sort - something which I cannot do in the C tsort. However, bash loops are notoriously slow, hence the more modules you throw at it the C tsort will overtake.

Attached is a patch (will apply to baselayout-1.12.0_pre10) that enables the C tsort. This is not being comitted to the tree as it adds more code, complexity and the C tsort may not be available all the time (/usr may be net mounted) and as proved, can actually be slower. What's more, it's unlikely that everyone will use the number of modules that I use (I have all of them "loaded" bar adsl) by the time we reach the sort, so bash is faster. :P So there. :P

However, there's not stopping you from seeing if you can improve it and tempt us into comitting it .... ;)

Discuss this Post