Kernel-space flirting with user-space

[devendra.aaru]

On Thu, Jan 10, 2013 at 4:09 PM, Simon <turner25 at gmail.com> wrote:
> Hi there,
>
>   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!  =)
>
>   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).
>
>   Secondly, I wonder how I can "bind" a user-space program/daemon with the
> kernel-space of the module.
>
>   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.
>   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?
>   Using pipes:  This may be a good way, but again, I'm not sure if it's the
> standard way.
>   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.
>   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.
>   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).
>   Using net interface: Not applicable.  And an experiment to try to make it
> applicable doesn't even seem remotely fun.  ;)
>
>   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.
>
>   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!)
>
> struct foo {...} outgoingFoo;
> // foo contains no pointers, so it is of a fixed size always.
> fwrite(&outgoingFoo, 1, sizeof(outgoingFoo), output);
>   [...then on the other end...]
> if(sizeof(fread( buffer, 1, buffer_size, input);
> struct foo * incomingFoo = (struct foo *) buffer;
>
> Regards,
>   Simon
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

What about netlink and mmap?