Hi Dave, My understanding was based out of linux/errno.h. Maybe the below comment is in context of glibc abstracting out ERESTART* error codes. #ifdef __KERNEL__ /* * These should never be seen by user programs. To return one of ERESTART* * codes, signal_pending() MUST be set. Note that ptrace can observe these * at syscall exit tracing, but they will never be left for the debugged user * process to see. */ #define ERESTARTSYS 512 #define ERESTARTNOINTR 513 #define ERESTARTNOHAND 514 /* restart if no handler.. */ #define ENOIOCTLCMD 515 /* No ioctl command */ #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */ ... #endif Rajat On Tue, Jan 11, 2011 at 9:32 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Rajat,
On Tue, Jan 11, 2011 at 2:10 AM, Rajat Sharma <fs.rajat@gmail.com> wrote:
is there any procedure in kernel to check for the interrupt vector number which caused it to be invoked? Its actually very architecture dependent, on x86, its 'int $0x80' which causes user space to call system calls handlers. Recent intel architectures have callgate mechanism to enter into system call, look for sysenter instruction. Anyways, are you interested in interrupt number or the system call number?
i mean like one of my friends said that when kernel is about to restart a syscall then it raises signal -ERESTARTSYS signal for signal handler.
Thats totally wrong. Like any other error code, its just an error code which waiting API return if process was interrupted while waiting on semaphore, e.g.
On the ARM platform, at least, if a syscall (like ioctl) returns -ERESTARTSYS, then the ioctl will be reissued after the signal handler runs.
I know this to be true, as I've verified it's functionality emperically. This is further supported by the kernel documentation http://lxr.linux.no/linux+v2.6.37/Documentation/DocBook/kernel-hacking.tmpl#...
Dave Hylands