Documentation / code sample wanted.

Documentation / code sample wanted.

[Jody Pearson]

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.

Re: Documentation / code sample wanted.

[Richard B. Johnson]

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.

Re: Documentation / code sample wanted.

[Alan Cox]

On Llu, 2003-06-02 at 18:40, Jody Pearson wrote:
> 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.

Thats basically impossible because gethostbyname will handle queries to
all kinds of things like LDAP or DNSSEC. Do your lookups in user space,
its a lot simpler.

Re: Documentation / code sample wanted.

[Matt Mackall]

On Mon, Jun 02, 2003 at 07:40:52PM +0200, Jody Pearson wrote:

> I am looking for some source code or a document which outlines how to open 
> a TCP connection within kernel space.

Take a look at nbd or Cisco's iSCSI driver.
 
> For more information, I basically want to emulate a userland 
> gethostbyname() in kernel space.

That gets ugly quickly. There are a lot of options and complexity
needed to handle even the simplest name resolution robustly. It almost
certainly makes more sense to do this in userspace and pass the result
down to the kernel.

-- 
Matt Mackall : http://www.selenic.com : of or relating to the moon

Re: Documentation / code sample wanted.

[Jody Pearson]

Hi Dick, All,

>
>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.
>  
>
In this case, I was being stupid with the gethostbyname exmaple. But I 
do know what a kernel is !

To fill in the blanks, I am writing a network based filesystem, and I 
now realise that the place to do the gethostbyname() is in a mount helper.

>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.
>
What I would like to achive is a self-contained module which implements 
a filesystem. The user-space apps then interact with the fs as normal.

I am trying to avoid havng "helper daemons" for various reasons, too 
long to go into here

>
>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.
>
And if your a filesystem ? Is it really recommended to do;

userspace->kernel->userspace->kernel->userspace ? That seems like a lot 
of context switching to me.

>
>You do this, by creating a user-mode daemon that
>sleeps in select() or poll() until the kernel code
>wakes it, 
>
[snip]

As I said, for my own reasons I would like not to have a deamon like this.

Thanks for the help.

Jody

-- 
Chaos, Panic, Pandemonium...  my work here is done.