syscall from modules

syscall from modules

[Amber Palekar]

 Hi,
   I am trying to write a linux kernel module.I want
 to  use sys_sendto,sys_recvfrom etc calls from the
 module.However these symbols are not present in
 'ksyms'.One sluggish option is to modify socket.c (
 which contains these function definitions ) to
 export  the symbols. However this would require
comiling the  entire kernel.Is there a descent way to
do this ??
 
 Pls help !!!
 Amber
 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: syscall from modules

[Trond Myklebust]

>>>>> " " == Amber Palekar <amber_palekar@yahoo.com> writes:

     >  Hi,
     >    I am trying to write a linux kernel module.I want
     >  to use sys_sendto,sys_recvfrom etc calls from the
     >  module.However these symbols are not present in 'ksyms'.One
     >  sluggish option is to modify socket.c ( which contains these
     >  function definitions ) to export the symbols. However this
     >  would require
     > comiling the entire kernel.Is there a descent way to do this ??

Hi,

Just use sock_sendmsg() and sock_recvmsg() directly. They are both
exported in netsyms.c.

Cheers,
  Trond

Again:syscall from modules

[Amber Palekar]

 Hi,
 
> Just use sock_sendmsg() and sock_recvmsg() directly.
> They are both
> exported in netsyms.c.
  Is there any specific reason behind not exporting
sys_sendto and sys_recvfrom ??

> Cheers,
>   Trond

TIA
Amber


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: Again:syscall from modules

[Terje Eggestad]

Yes, the sys_* funcs are declared asmlinkage int sys_*. 
where the asmlinkage differ from platform to platform. 
It's used to tell the compiler if a non standared calling 
convertion is used, typically if params are passed by registers
instead of stack. The asmlinkage define must be sett according to the
syscall dispatcher (entry.S on ia32), and may be changed accordingly. 

In short, if you want to use sys_* you must understand the interaction
between the sys_* funcs and the dispatcher on *every* platform, and
the interaction may change without notice.

In short short, don't don't don't don't use the sys_* functions.

TJ

On Tue, 2001-12-25 at 14:14, Amber Palekar wrote:
> 
>  Hi,
>  
> > Just use sock_sendmsg() and sock_recvmsg() directly.
> > They are both
> > exported in netsyms.c.
>   Is there any specific reason behind not exporting
> sys_sendto and sys_recvfrom ??
> 
> > Cheers,
> >   Trond
> 
> TIA
> Amber
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Again:syscall from modules

[Terje Eggestad]

Guess I should add that most sys_* functions are wrappers.

On Thu, 2001-12-27 at 16:54, Terje Eggestad wrote:
> Yes, the sys_* funcs are declared asmlinkage int sys_*. 
> where the asmlinkage differ from platform to platform. 
> It's used to tell the compiler if a non standared calling 
> convertion is used, typically if params are passed by registers
> instead of stack. The asmlinkage define must be sett according to the
> syscall dispatcher (entry.S on ia32), and may be changed accordingly. 
> 
> In short, if you want to use sys_* you must understand the interaction
> between the sys_* funcs and the dispatcher on *every* platform, and
> the interaction may change without notice.
> 
> In short short, don't don't don't don't use the sys_* functions.
> 
> TJ
> 
> On Tue, 2001-12-25 at 14:14, Amber Palekar wrote:
> > 
> >  Hi,
> >  
> > > Just use sock_sendmsg() and sock_recvmsg() directly.
> > > They are both
> > > exported in netsyms.c.
> >   Is there any specific reason behind not exporting
> > sys_sendto and sys_recvfrom ??
> > 
> > > Cheers,
> > >   Trond
> > 
> > TIA
> > Amber
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Send your FREE holiday greetings online!
> > http://greetings.yahoo.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Again:syscall from modules

[Trond Myklebust]

>>>>> " " == Terje Eggestad <terje.eggestad@scali.com> writes:

     > Yes, the sys_* funcs are declared asmlinkage int sys_*. where
     > the asmlinkage differ from platform to platform. It's used to
     > tell the compiler if a non standared calling convertion is
     > used, typically if params are passed by registers instead of
     > stack. The asmlinkage define must be sett according to the
     > syscall dispatcher (entry.S on ia32), and may be changed
     > accordingly.

     > In short, if you want to use sys_* you must understand the
     > interaction between the sys_* funcs and the dispatcher on
     > *every* platform, and the interaction may change without
     > notice.

     > In short short, don't don't don't don't use the sys_*
     > functions.

You are scaremongering a bit here. Several of the sys_* functions
*are* generic, and could be called by quite safely by the kernel. Look
for instance at the use of sys_close() by the binfmt stuff.

Normally, though, there will be a price to pay in terms of an
overhead.
Furthermore, if you find that you absolutely *have* to use the sys_*
interface, from userspace you will probably want to rethink your
design: after all you can call all those sys_* functions from user
space, and the rule of thumb is that if you *can* do something in user
space, you ought to do it there...

Cheers,
  Trond

Re: Again:syscall from modules

[Ralf Baechle]

On Thu, Dec 27, 2001 at 07:57:46PM +0100, Trond Myklebust wrote:

> You are scaremongering a bit here. Several of the sys_* functions
> *are* generic, and could be called by quite safely by the kernel. Look
> for instance at the use of sys_close() by the binfmt stuff.
> 
> Normally, though, there will be a price to pay in terms of an
> overhead.
> Furthermore, if you find that you absolutely *have* to use the sys_*
> interface, from userspace you will probably want to rethink your
> design: after all you can call all those sys_* functions from user
> space, and the rule of thumb is that if you *can* do something in user
> space, you ought to do it there...

Many sys_*() functions may be in the generic code but that still doesn't
mean the ports are actually using it or that no special calling sequence
which normally would be done in libc is required.  Only people doing
syscalls themselfes and not through libc wrappers is worse ...

  Ralf

Re: Again:syscall from modules

[Trond Myklebust]

>>>>> " " == Ralf Baechle <ralf@uni-koblenz.de> writes:

     > Many sys_*() functions may be in the generic code but that
     > still doesn't mean the ports are actually using it or that no
     > special calling sequence which normally would be done in libc
     > is required.  Only people doing syscalls themselfes and not
     > through libc wrappers is worse ...

Please read the beginning of the thread. The question was about
calling from within kernel space. No libc is or can be involved...

Cheers,
   Trond

Re: Again:syscall from modules

[Ralf Baechle]

On Fri, Dec 28, 2001 at 04:48:58PM +0100, Trond Myklebust wrote:

>      > Many sys_*() functions may be in the generic code but that
>      > still doesn't mean the ports are actually using it or that no
>      > special calling sequence which normally would be done in libc
>      > is required.  Only people doing syscalls themselfes and not
>      > through libc wrappers is worse ...
> 
> Please read the beginning of the thread. The question was about
> calling from within kernel space. No libc is or can be involved...

I was just comparing ...

  Ralf

Again:syscall from modules

[Trond Myklebust]

>>>>> " " == Amber Palekar <amber_palekar@yahoo.com> writes:

     >  Hi,
 
    >> Just use sock_sendmsg() and sock_recvmsg() directly.  They are
    >> both exported in netsyms.c.
     >   Is there any specific reason behind not exporting
     > sys_sendto and sys_recvfrom ??

Why would you want to do that when you already have a better kernel
interface available?

The sys_sendto, sys_recvfrom references the sockets by file handle,
something which requires an extra lookup operation to map the file
handle to socket struct.
OTOH sock_sendmsg(), sock_recvmesg() provides exactly the same
functionality, but takes a pointer to the kernel socket structure as
the argument.

Cheers,
  Trond