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