* Steven Rostedt (rostedt@xxxxxxxxxxx) wrote: > On Wed, 2011-01-19 at 11:15 -0500, Mathieu Desnoyers wrote: > > * Steven Rostedt (rostedt@xxxxxxxxxxx) wrote: > > > After applying David's "remove align" patch, I got it to boot on x86_64 > > > with the following two patches. I thought just adding the "align" to the > > > structure declaration would work, but it still failed on the syscall for > > > init_module. By removing the double "declaration" of event_exit_##sname, > > > removed this problem. > > > > > > I'll test this on x86 32bit and PPC 64. If it works there, I'll push all > > > of them out for 38. Should these go to 37 stable too? > > > > Please hold before adding these patches into git. They don't seem to address the > > underlying problem correctly. See the latest exchanges between David Miller and > > myself for more info. > > > > We need to come up with something better than "it boots" as an explanation for > > the fix. > > Yes, I agree that we should solve this issue correctly. But if there is > a work around to the problem, we could implement that if the real > solution is not in our grasp yet. A known working workaround (used in tracepoints for a few years) is to align the type declaration on 32 bytes. It wastes space, but works. With this solution, you should remove all the per-variable alignment attributes. Now what I'm discussing with David Miller is if creating a __long_packed_aligned and using it for *both* type and variable alignment would be more palatable (it also works, and is more compact). David proposed a solution with an array of pointers (extra indirection) which I don't really like for 3 reasons I exposed in my reply to him. So it's not that the solution is not in our grasp yet, it's more that we have to choose the right one. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- 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