Messages in this thread | | | Date | Mon, 2 Jun 2003 14:18:16 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: Documentation / code sample wanted. |
| |
On Mon, 2 Jun 2003, Jody Pearson wrote:
> Hi All, > > I am looking for some source code or a document which outlines how to open > a TCP connection within kernel space. > > After many google searches, and a search of the archives, I cannot seem to > find an example which says "do this". > > There are many references to sk_buff and friends, but nothing more > practical. > > I have looked over khttpd, which has been some help, and I looked briefly > at the nfs code, but I don't want to use RPC. > > Can anybody point me to a document/code/patch to help me out ? > > For more information, I basically want to emulate a userland > gethostbyname() in kernel space. > > Thanks > > Jody > > -- > Chaos, Panic, Pandemonium... my work here is done.
This has become a FAQ, probably because people don't know what a kernel is. They think it's just some 'C' code in which you can do anything the 'C' compiler lets you do.
Important! The kernel is not a 'task' it doesn't have a context. Everything it has been designed to do, is to perform systematic tasks upon behalf of the caller, calling from user-mode context. When it is executing, it is executing upon behalf of a user-mode task. It is doing what the user-mode task doesn't know how, or isn't trusted, to do.
The only thing that can call the kernel and successfully accomplish what it intended to do, is a user-mode task. Therefore, if you want to call the kernel, you do it from a user-mode program. It's just that simple.
For some reason, you want to translate the name of a host to its IP address or vice-versa from inside the kernel. Notwithstanding that it is patently absurd to require such text translation inside the kernel, it certainly is possible. The kernel code (a module) needs a user-mode daemon to perform user-mode tasks on its behalf.
This is bas-ackwards because code should be written the other way around, i.e., the kernel performs tasks upon behalf of a calling task.
You do this, by creating a user-mode daemon that sleeps in select() or poll() until the kernel code wakes it, using wake_up_interruptible(), after making information available (probably via ioctl()) about what the kernel code wants it to do. The user- mode daemon, awakened from poll() will perform an ioctl() and find out what the kernel code wants it to do. It will then do it, and pass the information to the kernel code via ioctl(), read() or write(). The kernel code will 'know" when the information has been returned because the user-mode daemon will then sleep in poll() or select() again.
You can also create a "kernel thread" to do something like this. However, nothing in the kernel can use the 'C' runtime library, running the risk of the kernel being called from that library. The interface to socket() stuff is a single kernel function, socketcall, function number 102. You don't want to have to do all the socket stuff by hand, you really want to use the 'C' runtime library, so you must use a user- mode daemon instead of a kernel thread.
Cheers, Dick Johnson Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
- 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/
| |