Hi Josip. > In this case the diff output isn't really useful, it has to be re-diffed > manually to see the actual difference. Granted, it's nothing important > in this case, but you should try to keep the mostly identical functions in > the same place in the same commit, and then move the new version into > a new place in a later commit, so that functional changes don't get > obscured by formatting changes. The sun4d_irq file almost saw an rewrite and as part of this I had to move the sun4d_init_timers function to avoid a forward declaration. I will try to do so in a preparational patch in v3 - the patch is in no way easy to review as it rewrites so much in one go :-) > > (Sorry not to be of any actual help - the oldest sparc machine I have access Peer review is great - please continue to do so! > to is an Ultra 5, and even that one is so slow that it makes the simple act > of compiling the kernel to test it - really tedious *shrug* :) I always build my kernels on my snappy Intel box (Intel Atom dual-core). I have a patch to crosstool-ng that I need to dust off and get submitted so it is trivial for others to build sparc toolchains too. But my sparc todo list is growing atm... Sam -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
