On Sat, 12 Feb 2000, Jeff Garzik wrote:
> Philipp Rumpf wrote:
> > IMHO it's better to just assume a "sane" compiler that doesn't pad things
> > if they're already naturally aligned (i.e. aligned to a multiple of their
> > size).
>
> If you care about padding or no, there are compiler attributes and
> options.
Indeed. I disagree with Russell:
On Sat, 12 Feb 2000, Russell King wrote:
> I wasn't saying that. However, I believe that the use of structures to
> represent hardware devices is abserd. All datasheets I have ever seen
> describe devices as a set of offsets from the start address.
>
> The raw information is numeric. Why go to the pain of converting this
> to a compiler-based structure, and then get the compiler to convert it
> back to offsets again? It's not like you're using typechecking or any
> other features of a structure.
Not all devices, especially the network cards, are simply a set of
offsets (though it's a bit academic, as it all turns into numbers in the
end!). We should be using the compiler to help us. It's good at working
out how to multiply and add to get the right offset - provided we give it
all the information in the first place - i.e. the necessary structure
packing
Can we all agree that the following is at least _acceptable_?
e.g.
struct rx_desc {
s32 base;
s16 buf_len;
s16 msg_len;
} __attribute__((packed));
...
struct rx_desc * rx_ring = ioremap(0xC0000, size_of_ring);
...
writel(value, &rx_ring[i].base);
writew(value, &rx_ring[i].buf_len);
...
iounmap(rx_ring);
My apologies for completely balls-ing up the initial patch. Now I
understand a little more about ioremap, given the above is acceptable,
I'll try to fix some of the drivers directly.
-- Peter Denison <peterd@pnd-pc.demon.co.uk> Linux Driver for Promise DC4030VL cards. See http://www.pnd-pc.demon.co.uk/promise/promise.html for details- 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 : Tue Feb 15 2000 - 21:00:23 EST