The HyperNews Linux KHG Discussion Pages

## problem with system call slot 167

  Forum: The Linux Kernel Hackers' Guide
  Re: Problem creating a new system call
  Re: Creating a new sytem call: solution (C.H.Gopinath)
  Keywords: printk SYMBOL_NAME sys_call_table entry.S unistd.h
  Date: Thu, 22 Jan 1998 17:18:44 GMT
  From: Todd Medlock <medlota@nu.com>

    I am using linux v2.0.33. In
     /usr/src/linux/arch/i386/kernel/entry.S
    SYMBOL_NAME slots 164,165,166 are as follows:

    .long 0,0
    .long SYMBOL_NAME(sys_vm86)

    I found that I could not add a new system call at 167. When
    I did, it was called by something else for who knows what
    reason. I know this because the only thing in my new system
    call was a printk statement (which displays whenever the new
     system call is called). With the system call at 167 I would
    receive unwanted printk messages at boot time, at shutdown
     time, and when I executed ifconfig! Hence, I put the
     following at 167 and put my new system call at 168.

    .long 0

    That seems to have made everything work! Another strange
    thing is that with my system call at 167 the insmod
    function reports "unresolved symbol" messages and will not
    install modules?? My guess is that one of the modutil
    modules is using the 167 slot! Anyone have any ideas?

    Regarding printk:

    It is my understanding that printk messages will appear on
    the console (I am assuming you are at a console if you are
    modifying system calls and generating the kernel ) as long
     as your message level is less then your log level. I use
     <0> for testing to be sure of having the lowest message level.
     For example:

    printk("<0>syscallname: entering my test syscall\n");

    This works for me.