Hi guys, Thanks for all the suggestion. Although this may be unusual way of transferring data between kernel and user level application, but this works very well. Only issue I had was to make sure that kernel module does not wait forever in case user application is gone. timer has taken care out it (send SIGTERM). I think I forgot to mention one important deign issue. The whole thing is started by the kennel module and user application keep waiting for kernel module to ask for work. Usman --- Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL> wrote: > On Wed, Sep 19, 2001 at 08:10:27AM -0700, Usman S. Ansari wrote: > > This was partly due to some design decisions which were taken before > > I started on this project. > > Fair enough. > > > The amount of data transfered between user and kernel is huge, for > > small amount of time now and than. > > That shouldn't be a problem. Accessing files on a fast RAID disk does > the same. > > > Test in last month or so has proved that this method works very well. > > This may or may not be a good design, but this is well understood, in > > terms of socket communication. I am sure there are other places where > > kernel proper uses this method to talk to user land. > > As a matter of fact, no. In the past the kerneld module loader was the > only program that used a different technique to talk to the kernel (it > used a SysV message queue), but right now the way to talk to userland > is by using device drivers. I think the reason you're facing so many > difficulties is in fact an indication that you're using the wrong way > to talk to userland. > > > Erik __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ - Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
