The 3.5 merge window has closed [LWN.net]

Linus Torvalds has released 3.5-rc1 which closes the merge window for this development cycle. "It's a pretty normal release - roughly 60% drivers, 20% arch updates, and 20% "all over" - filesystems, documentation, tools, you name it. [...] Depending on what your interest is, you might be excited about the CoDel packet scheduler, or about the GPU driver updates, or the new scsi targets. There is something in here for pretty much anybody." We covered what's been merged up through May 30 in two parts (1, 2) and will pick up any significant merges since then in next week's edition.

(Log in to post comments)

r1 breaks bluetooth for me

Posted Jun 4, 2012 10:42 UTC (Mon) by Pawlerson (guest, #74136) [Link]

Make a bug report then. It's rc1, so few things can be broken. LWN isn't a bug tracker.

r1 breaks bluetooth for me

Posted Jun 4, 2012 16:58 UTC (Mon) by dgm (subscriber, #49227) [Link]

If he's able to test an rc1 I would guess that he knows what to do. Besides, it's my impression that people used to comment this kind of thing on LWN not that long ago.

The 3.5 merge window has closed

Posted Jun 4, 2012 7:31 UTC (Mon) by neilbrown (subscriber, #359) [Link]

What would you consider to be a successful demonstration?

Just a simple test that it seems to do what the designs think it should do? Or a complete kernel an distro on a phone which saves power (how would I measure that exactly) and always responds properly to various events? Or something in between?

This isn't an idle question - I may well be experimenting with autosleep next week and having an external perspective on what to test would be valuable.

The 3.5 merge window has closed

Posted Jun 4, 2012 9:34 UTC (Mon) by liam (subscriber, #84133) [Link]

Hi Neil,

I'm not exactly sure, to be honest. Naively, perhaps, I would pair the kernel with the most stripped down distro I could find, let it boot to the prompt, and then do your tests from there (always measuring the Watts at the wall). That seems the simplest, non-trivial test.
You need not use an Arm platform to demonstrate this, but if you happen to have something like a trim slice, panda board, or raspberry pi lying about you could do something a bit more interesting. If this implementation of autosleep is similar to the one Rafael Wysocki did, you could try to run the Android userspace with the wakelock interface substituted with autosleep's. That may be impractical depending on how similar the interfaces are and how soon you would like this done. The advantage, of course, is you can get unambiguous results by comparing the three kernels (mainline, mainline with autosleep, and Android for reference).
For the actual tests, use the bltk framework. The statistics it produces, in this case, are of less interest than its ability to create easily repeatable loads.
If all of these seem a bit heavy, then booting to a prompt and running a script that simply echos key strokes would work if the kernel can buffer the key strokes that are used to wake the system.
I hope this was of some help because I'd love to see suspend being handled more intelligently on the desktop (well, laptop, really), but it does require very fast suspends and resumes, which isn't something the DE's are great at.

Best/Liam