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 <[email protected]> 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 > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
