lkml.org 
[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ioremap return type
From
Date
>>>>> "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(&regs->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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.119 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site