[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080220193709.GD21139@uranus.ravnborg.org>
Date: Wed, 20 Feb 2008 20:37:09 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: Michael Buesch <mb@...sch.de>
Cc: Gordon Farquharson <gordonfarquharson@...il.com>,
Russell King <rmk+lkml@....linux.org.uk>,
linux-kernel@...r.kernel.org, linville@...driver.com,
stefano.brivio@...imi.it, Linus Torvalds <torvalds@...l.org>,
Andrew Morton <akpm@...l.org>, viro@....linux.org.uk
Subject: Re: [RFC] [PATCH] Fix b43 driver build for arm
On Wed, Feb 20, 2008 at 03:44:04PM +0100, Michael Buesch wrote:
> On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote:
> > Hi Michael
> >
> > On Feb 19, 2008 3:41 AM, Michael Buesch <mb@...sch.de> wrote:
> >
> > > > [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff
> > > >
> > >
> > > That doesn't cause me to magically sign off this sort of patches, too.
> > > The sanity check is clearly broken in file2alias.c, as it checks something
> > > from the target kernel against the host environment it is compiled on.
> > > That doesn't make any sense at all.
> >
> > I think that you make some good points, but I'm at a loss as to how to
> > fix the problem. Do you have any suggestions?
>
> Remove the broken sanity check, if it's not possible the check there.
The check is valid for > 99% of the kernel builds as
cross compile builds are not that typical.
And the check is there for the sake of modutils.
The details I do not remember.
So we have a few possiblities:
1) Remove the consistency check and try to deal with the
rare cases where it fails and spend many hours investigating
before we realise it is difference in layout of data.
2) Pad a few structures with a few bytes so this consitency
check works even in cross build environments.
3) Detect that we are doing cross builds and skip the check
in this case.
Option 1) is the worst of the three as that can cost
of many hours bug-hunting.
Option 3) may seem optimal but I do not like to add more
complexity to this part of the build. And really I do not
know a reliable way to detech when we do cross builds anyway.
Leaving us with option 2) that is simple, strighforward and harmless.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists