LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Michael Buesch <mb@bu3sch.de>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Gordon Farquharson <gordonfarquharson@gmail.com>,
	linux-kernel@vger.kernel.org, linville@tuxdriver.com,
	stefano.brivio@polimi.it
Subject: Re: [RFC] [PATCH] Fix b43 driver build for arm
Date: Tue, 19 Feb 2008 06:32:29 +0100	[thread overview]
Message-ID: <20080219053229.GB25680@uranus.ravnborg.org> (raw)
In-Reply-To: <200802190101.27429.mb@bu3sch.de>

> > 
> > It is a consistencycheck between host and target
> > layout of data.
> > You need to pad the structure so it becomes 8 byte in size.
> 
> Ok, I looked at the code and it is hightly questionable to me that this
> check does work in a crosscompile environment (which the ARM build
> most likely is).
> 
> It seems to check the size of the structure in the .o file against
> the size of the structure on the _host_ where it is compiled.
> I can't see why we would want to check _anything_ of the target stuff
> to the host this stuff is compiled on.
> I can compile an ARM kernel on any machine I want.
> 
> There actually is a comment:
>  * Check that sizeof(device_id type) are consistent with size of section
>  * in .o file. If in-consistent then userspace and kernel does not agree
>  * on actual size which is a bug.
> 
> So it seems what this check _wants_ to compare the sizeof the structure
> in the kernel to the size of the stucture in the userland of the target system.
> But it does _not_ do that.
> It does compare the size of the structure in the kernel against the size of
> the stucture in userland on the machine it is _compiled_ on.
> That is wrong.
In at least 99% of the cases this is OK and the check has found
several bugs where things would not have worked due to different
alignmnet between kernel and userland. Just think about the
issues in a mixed 32/64 bit world.

In this particular case you _could_ be right that it would work
on ARM userland. But the only way to be sure is to pad the
structure so it become 8 byte in size.
Or as was recently done in the m68k case to tell the
compiler to specifically align it to 8 byte boundary.

	Sam

  parent reply	other threads:[~2008-02-19  5:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 22:03 Gordon Farquharson
2008-02-18 22:08 ` Michael Buesch
2008-02-18 22:13   ` Russell King
2008-02-18 22:24     ` Michael Buesch
2008-02-18 22:34       ` Russell King
2008-02-18 22:43         ` Michael Buesch
2008-02-18 22:50           ` Harvey Harrison
2008-02-18 22:56             ` Michael Buesch
2008-02-18 22:53           ` Russell King
2008-02-18 23:00             ` Russell King
2008-02-18 23:17               ` Michael Buesch
2008-02-18 23:42                 ` Sam Ravnborg
2008-02-19  0:01                   ` Michael Buesch
2008-02-19  4:59                     ` Gordon Farquharson
2008-02-19 10:41                       ` Michael Buesch
2008-02-20  0:44                         ` Gordon Farquharson
2008-02-20 14:44                           ` Michael Buesch
2008-02-20 19:37                             ` Sam Ravnborg
2008-02-22  4:24                               ` Gordon Farquharson
2008-02-22 12:08                                 ` Gordon Farquharson
2008-02-22 14:07                                 ` Michael Buesch
2008-02-23  4:34                                   ` Gordon Farquharson
2008-02-23  5:51                                     ` Michael Buesch
2008-02-23 10:14                                       ` Gordon Farquharson
2008-02-23 15:58                                         ` Michael Buesch
2008-02-26 14:37                               ` Ben Dooks
2008-02-26 16:12                                 ` Gordon Farquharson
2008-02-19  5:32                     ` Sam Ravnborg [this message]
2008-02-22 13:13                       ` Matthieu CASTET
2008-02-18 23:04             ` Michael Buesch
2008-02-19  8:37               ` Geert Uytterhoeven
2008-02-19 10:34                 ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080219053229.GB25680@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=gordonfarquharson@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=stefano.brivio@polimi.it \
    --subject='Re: [RFC] [PATCH] Fix b43 driver build for arm' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).