Messages in this thread | | | Date | Mon, 15 Nov 2004 15:10:52 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH] Regparm for x86 machine check handlers |
| |
On Mon, 15 Nov 2004, Randy.Dunlap wrote: > > and omit "asmlinkage.*sys_xyz". that leaves a handful of functions > which are <asm>, like: > > acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state); > csum_partial(), csum_partial_copy_generic(), > schedule_tail(), aes_enc_blk(), aes_dec_blk().
The schedule_tail() usage seems a bit suspect. The asm code on x86 seems to play it safe, and pass the argument _both_ on the stack and in registers. So it looks correct, but a bit schitzo.
The others should probably be changed to use register calling conventions, but it might not be worth doing so right now, and at least they seem to agree on how to pass arguments in callers and callee's. The csum functions are certainly performance-critical, but it's not like the argument passing convention is likely to make _that_ big of a difference, and they are "asmcall" not because they are called from asm, but because they are _implemented_ in asm (so unlike the other cases, these guys don't have the problem with the callee thinking it owns the argument frame).
> I don't see others than need to be fixed, but a script > would be a safer way to check, so I'm trying to nail down > the requirements ... and what tool to use, like is there > already a PERL [or python or xyz] script that parses C, > or would you *coff* recommend sparse?
Sparse can't look into the asm code, but it could certainly be made to report on functions that use "regparm(0)". But it would be good to have something that matches up the functions with the asm code and verifies that they agree on passing convention.
There doesn't seem to be enough of them to bother with a tool, though.
Linus - 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/
| |