On Sat, 24 Jun 2000, Urban Widmark wrote:
>So all drivers (I'm sure there are a few) that use something like
>
>struct foo {
> u32 a;
> u32 b;
> u32 c;
> u32 d;
>}
>
>to communicate with some hardware (4 32-bit values with addresses in
>sequence) should be fixed not to make assumptions about the layout of a
>struct?
Yes. And also iphdr and tcphdr are apparently broken as well (and that
have implications in libc and userspace proggy too).
Despite of backwards compatibility issues using struct for iphdr and
friends is much more clean than having to use an array. So I suggest to
left the reordering disabled at least for struct as default (if gcc folks
implements the reordering I suggest to make it a global flag that can be
enabled _only_ by demand). Then we need also an new attribute that force
the fields of a structure not to be reordered. And then somebody can try
to compile with the reordering in the structs once all software will use
the new attribute properly. Maybe packed could be re-used also for that
but probably it's cleaner to take the two semantics separate in two
separate attributes.
BTW, we also do cacheline optimizations relying on the ordering of the
fields and I guess the compiler will have a very hard time to get smarter
than us in doing such optimizations ;)). So it's not obvious to me which
is the point of reordering the fields (except maybe an alien architecture
that I don't have in mind at the moment).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:04 EST