[lkml]   [2004]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] arch-specific cond_syscall usage issues
On Fri, Jan 09, 2004 at 07:37:53PM -0800, Andrew Morton wrote:

> Matt Mackall <> wrote:
> >
> > Experimenting with trying to use cond_syscall for a few arch-specific
> > syscalls, I discovered that it can't actually be used outside the file
> > in which sys_ni_syscall is declared because the assembler doesn't feel
> > obliged to output the symbol in that case:
> >
> > weak.c:
> >
> > #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall");
> > cond_syscall(sys_foo);
> >
> > $ nm weak.o
> > U sys_ni_syscall
> >
> > One arch (PPC) is apparently trying to use cond_syscall this way
> > anyway, though it's probably never been actually tested as the above
> > test was done on a PPC.
> So why does the PPC kernel successfully link?

Since this looks to have missed -mm3, I'm going to follow up here (I
hate playing catch-up sometimes).

As has been previously noted, the cond_syscall is only ever cared about
on PPC when you try for !PCI. And this only happens realistically now,
on MPC8xx (it's usually present on IBM 4xx, and lets ignore APUS).
MPC8xx support has been broken for a while, but hopefully will get fixed

So can we please move this cond_syscall into kernel/sys.c ?

Tom Rini
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.092 / U:0.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site