[lkml]   [2003]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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.

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:35    [W:0.025 / U:4.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site