> asmlinkage is defined for almost all arch: > grep asmlinkage arch/arm/*/* and u got the answer.
I didn't see a definition of macro atleast in linux source I was browsing (3.2.0), Could you please point out to any one you have found. Alternatively I tried more precise search: linux-source-3.2.0$ grep -R "#define asmlinkage" arch/arm/ No output. Although similar search gave following result for x86: linux-source-3.2.0$ grep -R "#define asmlinkage" arch/x86/ arch/x86/include/asm/linkage.h:#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0))) arch/x86/include/asm/linkage.h:#define asmlinkage_protect(n, ret, args...) \ Typically it should be defined in arch specific linkage.h file only, for arm there was none I found. If none is found, default definition is given from inlucde/linux/linkage.h which is nop: #ifndef asmlinkage #define asmlinkage CPP_ASMLINKAGE #endif CPP_ASMLINKAGE is just extern C stuff: #ifdef __cplusplus #define CPP_ASMLINKAGE extern "C" #else #define CPP_ASMLINKAGE #endif Indeed the only meaningful definition I found for x86_32 only in arch/x86/include/asm/linkage.h: #ifdef CONFIG_X86_32 #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0))) regparm controls number or integer arguments passed to a function. And it is specific to x86 only according to gcc manuals. Hence the above wiki FAQ seems valid for x86_32 arch, although it should specifically mention this arch dependence to avoid confusion on public forums. -Rajat On Fri, Jan 11, 2013 at 8:43 AM, Peter Teoh <htmldevelo...@gmail.com> wrote: > asmlinkage is defined for almost all arch: > > grep asmlinkage arch/arm/*/* and u got the answer. > > It seemed that: > > http://kernelnewbies.org/FAQ/asmlinkage > > gave the impression that asmlinkage is only for system call, or associated > with it. Not really, nothing to do with system call actually. > > Even though majority (or ALL) of syscall are defined with asmlinkage, but > there are many that are not, eg, in arch/arm subdirectory: > > kernel/irq.c:asmlinkage void __exception_irq_entry > kernel/process.c:asmlinkage void ret_from_fork(void) > __asm__("ret_from_fork"); > kernel/smp.c:asmlinkage void __cpuinit secondary_start_kernel(void) > kernel/smp.c:asmlinkage void __exception_irq_entry do_IPI(int ipinr, > struct pt_regs *regs) > > just a few examples. Essentially, it is just declared so that the name, > for example, "do_IPI" can be called from assembly, for example in the > following pair (arch/arm assumed): > > /kernel/smp.c: > asmlinkage void __exception_irq_entry do_IPI(int ipinr, struct pt_regs > *regs) > > ./include/asm/entry-macro-multi.S: > bne do_IPI > > More info: > > > http://stackoverflow.com/questions/10060168/is-asmlinkage-required-for-a-c-function-to-be-called-from-assembly > > From above, asmlinkage is also NOT the only way...... > > > On Fri, Jan 4, 2013 at 6:29 PM, anish singh > <anish198519851...@gmail.com>wrote: > >> On Fri, Jan 4, 2013 at 3:41 PM, Rajat Sharma <fs.ra...@gmail.com> wrote: >> >> Is this correct for all architectures? >> > >> > I guess not, asmlinkage is undefined for arm, so I assume this >> mechanism is >> > not there for arm. >> then how do they do it? >> > >> > >> > >> > On Fri, Jan 4, 2013 at 2:24 PM, 卜弋天 <bu...@live.cn> wrote: >> >> >> >> >> >> >> >> 在 2013-1-4,15:38,"Rajat Sharma" <fs.ra...@gmail.com> 写道: >> >> >> >> > So with asmlinkage we request compiler to put args on stack. What is >> >> > advantage of this to start_kernel or in general to other functions ? >> >> >> >> See its about implementation ease and little of performance too. >> Assuming >> >> the default model of keeping arguments in registers is used. lets say >> >> arguments are assumed to be in registers R1, R2, R3, R4, R5, R6 and >> beyond >> >> that in stack. Since system call number is a transparent argument >> which is >> >> chopped off when calling the actual kernel handler and if R1 had the >> system >> >> call number, then you have to shift all register values and stack >> arguments >> >> too. >> >> >> >> Is this correct for all architectures? >> >> >> >> As I remembered, ARM uses SWI instruction to implement the system >> call, >> >> it will pass system call number by register R7, and use normal register >> >> R0~R3 to pass parameters. >> >> >> >> >> >> >> >> Now consider that all arguments are pushed on stack (as enforced by >> >> asmlinkage), you have all function argument in the beginning of the >> stack >> >> and the system call number on top of the stack. you just need to pop >> out >> >> stack top to remove system call number from function argument. >> >> >> >> You might argue that why not always keep system call number on stack >> top >> >> and use registers for function arguments? But thats part of the >> compiler ABI >> >> and if you had fewer arguments lets say 2 only and used up R1 and R2 >> only, >> >> you may not jump to stack top directly for storing system call as its >> turn >> >> for R3 as argument. >> >> >> >> So, isn't it simpler implementation with everything on stack? >> >> >> >> -Rajat >> >> >> >> >> >> On Fri, Jan 4, 2013 at 12:13 PM, Rahul Bedarkar <rpal...@gmail.com> >> wrote: >> >>> >> >>> Thanks. So with asmlinkage we request compiler to put args on stack. >> What >> >>> is advantage of this to start_kernel or in general to other functions >> ? >> >>> >> >>> Regards, >> >>> Rahul >> >>> >> >>> >> >>> On Thu, Jan 3, 2013 at 9:34 PM, Mulyadi Santosa >> >>> <mulyadi.sant...@gmail.com> wrote: >> >>>> >> >>>> On Thu, Jan 3, 2013 at 7:40 PM, Rahul Bedarkar <rpal...@gmail.com> >> >>>> wrote: >> >>>> > Hi, >> >>>> > >> >>>> > I was searching for asmlinkage and found that it is already >> explained >> >>>> > at >> >>>> > http://kernelnewbies.org/FAQ/asmlinkage >> >>>> > >> >>>> > But I didn't get this. Can someone tell me about it in brief ? >> >>>> >> >>>> the point is, parameters which is usually passed via stack, is passed >> >>>> using different way. >> >>>> >> >>>> A good example is system call.... they are passed using registers >> IIRC >> >>>> >> >>>> >> >>>> -- >> >>>> regards, >> >>>> >> >>>> Mulyadi Santosa >> >>>> Freelance Linux trainer and consultant >> >>>> >> >>>> blog: the-hydra.blogspot.com >> >>>> training: mulyaditraining.blogspot.com >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Kernelnewbies mailing list >> >>> Kernelnewbies@kernelnewbies.org >> >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >>> >> >> >> >> _______________________________________________ >> >> Kernelnewbies mailing list >> >> Kernelnewbies@kernelnewbies.org >> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> > >> > >> > _______________________________________________ >> > Kernelnewbies mailing list >> > Kernelnewbies@kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > > -- > Regards, > Peter Teoh >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies