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
hi,
if i export these syms .. firstly ill have to
change the source/patch the kernel which is not
advisable then every time i write such a module .. ill
have to make sure that i export all these symbols and
there are no conflicts due to some wierd deps that
might be present ( u never know ! ) So i am looking
for a descent way to do the same
Still in need of help,
Amber
--- vda <[email protected]> wrote:
> On Tuesday 25 December 2001 09:31, Amber Palekar
> wrote:
> > 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 ??
>
> I don't know much about module writing.
> Why do you think it's wrong to export those fns?
> --
> vda
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
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
>>>>> " " == Amber Palekar <[email protected]> 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
>>>>> " " == Amber Palekar <[email protected]> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>>>>> " " == Terje Eggestad <[email protected]> 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
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
>>>>> " " == Ralf Baechle <[email protected]> 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
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