Ingo Molnar wrote: > * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > >>> found a couple of bugs. >>> >>> firstly, 64-bit wasnt so lucky, you broke >>> iounmap()/change_page_attr() >>> :-) >>> >> Crap. Worked for me. I'll look into it. >> > > well, there's an easy solution for unification patches: the resulting > object files must have _exactly the same_ content as without the > unification patches. (Modulo strings as WARN_ON()s referring to > include-file names.) > > If they differ then the unification did something wrong. With your > patchset and the config i sent, the difference is visible in the image > size already: > > text data bss dec hex filename > 7763766 967330 5812328 14543424 ddea40 vmlinux.after > 7763811 967330 5812328 14543469 ddea6d vmlinux.before > > also, reducing the size and scope of changes helps as well - because > that way it can be bisected down to specific changes. Mistakes > inevitably happen, especially if you do not enforce a rigid > byte-for-byte correctness along the way. You did 5 rather large patches, > and it's not testable because your unification steps were too coarse. >
But byte-for-byte identity isn't (necessarily) possible when actually unifying. If the same function exists in different forms on 32- and 64-bit, then unifying requires I pick one of them (or perhaps a new superset) to use in the unified form. That function may generate different code compared to the one that it replaced... But you're right, I can do the patches in a more piecemeal form. I'll see if I can rework them. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
