Subject: Re: SYS___syscall and linux (etc) compatibility
From: David Laight <firstname.lastname@example.org>
Date: 07/04/2003 17:29:38
On Fri, Jul 04, 2003 at 05:08:03PM +0100, Ben Harris wrote:
> In article <20030704165105.A12254@snowdrop.l8s.co.uk> you write:
> >AFAICT the kernel system call entry (esp. the i386 one) assumes that
> >system call 198 is sys___syscall (ie the actual system call number
> >is the first 64bit argument).
> >However it does this before consulting the p->p_emul->e_sysent
> >This means that:
> >1) Anything trying to do syscall 198 on any emulation is doomed.
> >2) Anything trying to do sys___syscall on an emulation is probably doomed.
> >Have I missed something obvious???
> I think I modeled our ARMLinux emulation on the i386 code, and on ARM we
> have separate linux_syscall_plain() and linux_syscall_fancy() functions
> which get used in place of syscall_plain() and syscall_fancy() for Linux
> processes. swi_handler calls theough p->p_md.md_syscall to select the right
> one. I suspect i386 is similar.
Thanks - I suspect I was confused by the unecessary use p->p_emul->e_sysent
when the array could be accessed directly - which should shave a few cycles
off the syscall entry path.
I was looking at this code with a view to adding a per-syscall counter.
(I want to know which syscall a shell script I have manages to do
300000 of a second - so I can fix the script and/or shell.)
David Laight: email@example.com