Kernel-space flirting with user-space

[fs.rajat@gmail.com (Rajat Sharma)]

If you do not have much dependency to be in kernel mode, you can implement,
or atleast initially, a user mode filesystem using fuse.
------------------------------
From: Simon
Sent: 11-01-2013 02:45
To: kernelnewbies at kernelnewbies.org
Subject: Kernel-space flirting with user-space

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130110/44cd14aa/attachment-0001.html