[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070617223436.2125b1a4.akpm@linux-foundation.org>
Date: Sun, 17 Jun 2007 22:34:36 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Frysinger <vapier@...too.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [patch] make hdrscheck.sh force __asm__ in exported headers
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <vapier@...too.org> wrote:
> On Monday 18 June 2007, Andrew Morton wrote:
> > On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <vapier@...too.org> wrote:
> > > This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> > > rejecting them in favor of __asm__() in exported headers.
> >
> > And does the kernel pass these checks?
>
> nope ... should i audit the arches before this gets merged ?
Yes please. I'd rather not break things in this fashion: it causes a storm
of emails which I need to redirect to the appropriate maintainers who then
take an arbitrarily long time to do anything. Meanwhile lots of testers
get impacted and this reduces the testing level of all the other thousands
of patches in there.
> > Which architectures have been tested?
>
> i386 passes, blackfin/x86_64 fail a simple asm/unistd.h, and x86_64 fails a
> bunch in asm/msr.h, but last time i tried to patch that, the maintainer said
> they were going to be hiding a bunch of that stuff anyways
Well I would prefer that we merge as many fixes as poss into -mm before
merging this patch - to reduce the impact on testers.
If these fixes are "wrong" but work then that's fine. I just keep spamming
the maintainer with the wrong-but-works patch until he wakes up and fixes
it for real.
Also, your changelog sucks:
This updates scripts/hdrschecks.sh by grepping for asm() constructs and
rejecting them in favor of __asm__() in exported headers.
well OK. But for what reason? We can see a lot of pain in this patch but
no gain. The changelog should tell us what the benefit is, so we can make
informed tradeoff decisions.
-
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