Kernel-space flirting with user-space

Simon turner25 at
Wed Jan 16 12:28:25 EST 2013

Hi Henrique,
  I browsed the two links and I think I've read parts of the LDD3, but I
could find an answer to my questions.  But considering it is sold as a real
book, I might prefer to buy it.  I find it easier to read in a book than on
screen, for large texts at least.

  And the second link with the howto is seriously impressive!  In fact, if
I had found it earlier, I don't think I would have needed to write my OP!

Thank you very much,

On Thu, Jan 10, 2013 at 10:05 PM, Henrique Rodrigues <
henriquesilvar at> wrote:

> I think the LDD book is a good starting point:
> You can find some examples of kernel/user communication here:
> --
> Henrique Rodrigues
> On Thu, Jan 10, 2013 at 1:09 PM, Simon <turner25 at> 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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Kernelnewbies mailing list