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[]
> >structure.
> >
> >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

-- 
David Laight: david@l8s.co.uk