Porting an element from user level to kernel level?
Juan Luis Baptiste
juancho at linuxmail.org
Wed Mar 26 21:08:32 EST 2003
Hi,
I have noticed that I can't use snprintf() calls in kernel-level, but sprintf() are allowed. If I can't specify the number of bytes to be written to a string, how I can prevent my code from a buffer overflow?
Cheers,
Juan Luis
----- Original Message -----
From: Eddie Kohler <kohler at icir.org>
Date: Sun, 16 Mar 2003 22:05:21 -0800
To: "Juan Luis Baptiste" <juancho at linuxmail.org>
Subject: Re: Porting an element from user level to kernel level?
> I'm porting my elements to kernel level, but I'm having a lot of compile problems with functions that I cannot use in kernel level.
> Most of the problems are with functions of stdlib.h, like malloc, calloc and free. Also something about conflicting types:
> "conflicting types for 'typedef __dev_t dev_t' and '__kernel_dev_t dev_t'", and network functions like inet_ntoa(), inet_ntop(),
> inet_pton(), etc.
Juan Luis,
Most functions in stdlib.h are not available in the kernel. Most C library
functions are not available in the kernel. Types like dev_t are not
available in the kernel. Functions like inet_ntoa are not available in the
kernel.
Kernel programming is very different from user-level programming. No file
access. No standard library.
Your best bet is to use Click functions exclusively. For example inet_ntoa
is silly when you have "IPAddress::unparse()". If it is not wrapped by
Click, the functionality is not likely to work in the kernel.
Eddie
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
More information about the click
mailing list