I think you have misunderstood what I was getting at. I didn't mention using
libc inside the kernel, which you cannot do. Besides, at some point,
libc must make the system call to the kernel to actually perform what is requested.
What I was suggesting was doing the same thing that
libc does, but bypassing the wrapper functions that include the kernel space to user space string/data copying code so the call and data says within kernel space. Since the execution path is already in kernel space, you can call the implementation function directly. You will need to trace through the source and find the kernel entry-point for functions that perform open, close, read, and write though. There are two or three layers of wrapper functions involved before you get to the actual implementation of the function. If the wrapper functions are bypassed, and all the parameters are correct, the kernel does not make the distinction as to where the call came from. All it knows is that someone requested it to perform some action. To my knowledge, there is nothing that says that this cannot be done. However, in doing things this way, a programmer must perform all manipulation of data manually as the "nice"
libc functions are not available. If you are reading in a text file, then the programmer must break the data up into individual lines and such as the incoming data is considered to be raw binary.
I disagree with your assessment that the kernel does not know about user space objects, files in particular. By definition, the kernel must know about files because it is the kernel that must manipulate the file to perform the requested functions such as open, close, read, write, stat, etc. Additionally, you don't even need to use functions like
open(2). By using
syscall(2), you can more or less bypass all the "nice" functions in
libc and talk to the kernel directly from your application.