Kernel-space flirting with user-space

[Henrique Rodrigues]

I think the LDD book is a good starting point: http://lwn.net/Kernel/LDD3/

You can find some examples of kernel/user communication here:
http://people.ee.ethz.ch/~arkeller/linux/kernel_user_space_howto.html

-- 
Henrique Rodrigues
http://www.dcc.ufmg.br/~hsr

On Thu, Jan 10, 2013 at 1: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130110/87612990/attachment.html