Re: Read from file fails

[Libor Vanek <libor@conet.cz>]

> I will explain for the Nth time. The kernel is a bunch of code
> that performs functions on behalf of a process. It does that in
> the context of that process. A file descriptor is a number that
> belongs to a process. It is worthless without a process with which
> to associate. If the kernel were to open a file, who owns the
> file descriptor? The kernel isn't a process, it's a big LIBRARY!

OK - speaking of this I just want call one public (exported) function of library from another.

> So, if you are lucky, you can steal the context from another
> unknowing process. This works unless there was a context-switch or
> if the process was asleep so it didn't access any files of
> its own. It leaves the kernel in a bad state because there
> is a wild file-descriptor that nobody owns that will never be
> closed because when your cludge closes that file-descriptor, you
> probably end up closing STDOUT_FILENO of some important task
> that you haven't discovered yet.
> 
> The cludges that work involve creating a "kernel thread" which
> has a process context. That thread does the file I/O. However,
> it's certainly easier to create a user-mode task (program) that
> opens your module and, using an ioctl(), sends it anything from
> anywhere in the known universe. You can get data from a file or
> from anywhere.

OK - so speaking of kernel thread - what function should I use? Or do you think that only the difference of having process context and pid will cause read to work? (I'm willing to believe it ;-) - I'll try it later)

I think there are reasons (speed, speed, speed...)  why some things should be done kernel-space. And I think that this is one of them. I know that I'll never want to "send data from anywhere in the known universe" (famous last words?) - I just need to create backup copy of file.


Libor