-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Thanks for your reply, Tyler =) > > Hi Mike, > > in fact, you can't use the same spinlock in the user mode and in the > kernel mode. that's because the adress spaces aren't the same in kernel > and user mode. > And generally, you don't share a buffer between kernel and user space. > Okay, sure, fair enough.. My design makes use of a struct that is allocated when the char device is opened, that contains two 'char[BUFSIZE]' buffers, and, currently, an atomic_t mutex. The character device's mmap() handler maps this struct to the requesting process's memory space, so they can share it. I've chosen to implement it using mmap() so that copying could be kept to a minimum; if I was using read()/write() methods instead, there'd be more copying of data happening, which would be a performance hit, albeit not a huge one. Unfortunately, the problem with shared memory is synchronisation, which is where the difficulty arises. Stepping back a bit, what I'm actually implementing is a layer 2.5 ad-hoc network driver, that sits beneath TCP/IP and friends, and above the device driver; Portability was a priority (will probably be implementing it under FreeBSD and co in the future as well), which was why a module/daemon architecture seemed like a good idea. So the daemon needs to get access to packets coming off the wire (or air, as the case may be), and needs to be able to write packets onto the physical device, and also needs to get packets coming from the virtual network device, and put packets onto the virtual network device, passing them up to higher layers. > I don't know exactely what you want to do but I think you have to build > a new design of your module. > Looking at the scheme, you seem to use char drivers. > Have a look here : > http://lwn.net/Kernel/LDD3/ > > If it's a char driver you want to do, implement the buffer in kernel > space and just provide the good functionnalities (read,write) so the > users will be able to access the data. > Ahh, good ol' LDD3, what would I do without you.. =) I've read through a lot of that stuff, which was how I determined how to implement the mmap() handler.. I do fear that just giving userspace access to the buffer via read and write will cause a performance bottleneck, as every packet has to be read/written twice - Once to read from the network device, once to write the unencapsulated packet back to pass to higher layers. At multi-megabit speeds, running full tilt, that's a fair amount of data transfer going on.. What you think? Am I still going to get away with using mmmap? Thanks heaps =) Mike > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > - -- Mike Tyson <mike@xxxxxxxxxxxxx> M: (+61) 0407 754 124 W: http://tzidesign.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCsMeu/eih+gEb7pQRAt5bAKDr3NnOvOQikV/dItheBj7qCwpCrACfRZwe h5rs6jhZSCRvzLkyMNXgYgg= =d2Eh -----END PGP SIGNATURE----- -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
