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@xxxxxxxxx> wrote: > Hi Rajat, > > On Tue, Jan 11, 2011 at 2:10 AM, Rajat Sharma <fs.rajat@xxxxxxxxx> 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#L346 > > Dave Hylands > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
