>
>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.
- 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/