On Thu, Jan 10, 2013 at 4:09 PM, Simon <turner25@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
What about netlink and mmap?
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
