Messages in this thread | | | Date | Mon, 3 May 2004 17:06:06 +0200 | From | Libor Vanek <> | Subject | Re: Read from file fails |
| |
> 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
- 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/
| |