Messages in this thread | | | Subject | Re: ioremap return type | From | Jes Sorensen <> | Date | 11 Aug 2000 17:24:30 +0200 |
| |
>>>>> "Philipp" == Philipp Rumpf <prumpf@parcelfarce.linux.theplanet.co.uk> writes:
Philipp> On Thu, Aug 10, 2000 at 02:14:13PM +0200, Jamie Lokier wrote: >> Many drivers use a struct to define the offsets in their I/O or >> iomem space. E.g. acenic.c: readl(®s->CpuCtrl). We know that's >> not portable in the sense that struct layout is not guaranteed. >> However, provided all the fields are suitably padded & aligned, it >> works in practice. (So far..)
Philipp> Not only does it work in practice, it's used by most drivers Philipp> and file systems when they describe on-disk or dma Philipp> structures. Currently the rules are:
Philipp> - naturally align everything - all struct sizes might be Philipp> aligned to a multiple of four bytes
Philipp> By now, I believe it is more likely that gcc would be fixed Philipp> for a new architecture that violates this assumption, so it's Philipp> not worth it to go around and "fix" those drivers.
Nononononono, gcc on the m68k does 'natural' alignments to two byte boundaries and not 4 bytes. Yes it sucks and no we cannot change it now.
If you use structures to describe hardware you should *always* perform explicit padding and never ever expect the compiler to do it for you. Just because it works on one architecture doesn't mean the alignments will be the same on another, and it is not just a question of fixing the compiler, if the architecture ABI says on thing then thats normally what to listen to.
Jes
- 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/
| |