On 6 July 2012 19:00, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Jul 06, 2012 at 05:19:10PM +0100, Peter Maydell wrote:
Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
Wow. That's a lot of months off-plan! I like it that you have the planned dates so I don't want to complain about it, but in your mind why did this take so long?
A combination of: * I'm not very good at estimation, and going through all the cp15 registers and converting them took much longer than I expected * we ran into the combination of QEMU-upstream-freeze, Connect and my holiday, which accounts for 7-8 weeks all on its own where the status was basically "complete but not landed upstream" * we rearranged the schedule in early Feb when it became clear that this cp15-rework wasn't an absolute dependency for us to hit the initial milestone for Connect in SF, so we did various other tasks instead and cp15-rework went on the back burner for a month or two * some underestimation of how much time I would spend doing this dev work rather than other things (like qemu-linaro releases, upstream maintainer work, etc).
||a15-lpae-support || 2012-07-13 || 2012-07-13 || || ||clean-up-kvm-patches || || || || ||track-kvm-abi-changes || || || || ||fake-trustzone || || || ||
Also, are you planning on having planned/estimate entries here, given your "by-August" entry?
It's a bit tricky because the set of work we ended up with in the 'by August' card doesn't neatly line up with the blueprint boundaries, and also because there's a bunch of stuff on the card which is "wait for kernel side implementation then do a small amount of QEMU side work", and which I therefore can't provide estimate dates for because I have no idea when the kernel will be done. There's also a chunk of work I wasn't expecting to see on the card (though I don't disagree that it's there) and which thus doesn't yet have an underlying blueprint. I'll try to clean this up a bit for next week so that bit at least has some plan/estimate dates.
- discovered that Linux will happily throw away the top 32 bits of a device tree memory node's size field. Wrote a patch for this, which works but needs redoing to fix in a cleaner way.
That's weird. Why would it do that?
Because historically the assumption in arch/arm has been that you can't possibly have a memory size that won't fit in 32 bits because physical addresses are 32 bits; this is just a dangling assumption that never got fixed. See thread on linaro-dev for technical detail.
-- PMM