Messages in this thread | | | Date | Sun, 17 Jun 2007 22:34:36 -0700 | From | Andrew Morton <> | Subject | Re: [patch] make hdrscheck.sh force __asm__ in exported headers |
| |
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 18 June 2007, Andrew Morton wrote: > > On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <vapier@gentoo.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |