<div>Hi there,<br></div><div><br></div><div> I'm rather new to kernel development, but I am somewhat experienced with Linux, kernel compilation, etc. I'm just passed writing a helloworld module, dummy filesystem (ramfs wrapper) and proc entry. I would like to know how communication between kernel & user-space is done (the standard) for a high number of tiny and large messages going in both directions (large messages would need to be transfered incrementally, in chunks, can be sequential or random access). I plan on developping a network filesystem. I would appreciate if someone could clarify where I'm wrong and confirm where I'm right, and ideally suggest some vocabulary, source files to lookup, online docs or even books. The minimum you can give will be most appreciated! =)</div>
<div><br></div><div> Firstly, I was wondering if it would be possible to implement the filesystem entirely as a kernel module. I would need TCP/UDP sockets. I think this is really not the recommended approach, but an advantage I see is it could be used to mount the root filesystem before calling init (that would be before user-space exists, right?). On the other hand, separating the work to have a program/daemon in user-space do the communication and processing would allow me to write that part in C++ (which I personally prefer).</div>
<div><br></div><div> Secondly, I wonder how I can "bind" a user-space program/daemon with the kernel-space of the module.</div><div><br></div><div> Using procfs: It seems technically possible to achieve my goal with it, but I feel this would not be the standard approach. I would rather keep it for live config & live status reporting.</div>
<div> Using sysfs: I've read too much misleading information that I'm not sure anymore what it's for or even if it's still used or deprecated! Can someone clarify? It looks technically identical to procfs, but it's mission is a different one, correct?</div>
<div> Using pipes: This may be a good way, but again, I'm not sure if it's the standard way.</div><div> Using IPC: As far as I understand, IPC would be the way if we'd be talking of two threads within the same process, or at least within kernel-space. Though I am likely to be wrong.</div>
<div> Using a char device: It seems technically possible as well, but it may be difficult to deal with if I ever have more than one user-space process.</div><div> Using a block device: My file system works with files and their metadata, but not with blocks, so this is not suitable. Though it might be a nice experiment to build a network block device containing an ext2 filesystem (which I think would be similar to iSCSI).</div>
<div> Using net interface: Not applicable. And an experiment to try to make it applicable doesn't even seem remotely fun. ;)</div><div><br></div><div> I've seen the functions copy_to/from_user() or something like that, but I haven't seen the user-space counter-part of these. I think this may actually be the best approach by far, but I really lack info/docs to go that way. The truly best way might be to use shared memory to avoid copying data internally, but I haven't looked into that much yet.</div>
<div><br></div><div> Finally, is it possible/correct/standard to do something similar to the following for the local kernel & user-space communication? (I haven't reviewed the syntax, so take it as some kind of pseudo-code!)</div>
<div><br></div><div>struct foo {...} outgoingFoo;</div><div>// foo contains no pointers, so it is of a fixed size always.</div><div>fwrite(&outgoingFoo, 1, sizeof(outgoingFoo), output);</div><div> [...then on the other end...]</div>
<div>if(sizeof(fread( buffer, 1, buffer_size, input);</div><div>struct foo * incomingFoo = (struct foo *) buffer;</div><div><br></div><div>Regards,</div><div> Simon</div>