On Tue, Jul 16, 2002 at 01:10:04PM +0300, Nadav Har'El wrote: > On Tue, Jul 16, 2002, Muli Ben-Yehuda wrote about "Re: device files implementing >mmap": > > It's not if you use the double buffer, since you always get old but > > correct data. If you use a single buffer, you might get garbage > > (you're reading a chunk, and as you read it, it gets overwritten by > > the kernel). > > I suggested a way to solve this: your driver will refuse to overwrite the > last returned chunk (it knows what it returned last!) and start dropping > new data (it's a bit harder to drop old data in this scenario, but probably > doable with a bit of cleverness) when the beginning of that chunk is reached > again.
The membuf already supports dropping new data on overflow, dropping old data on overflow and 'strict mode', where if you ask to add more data than there's room for, you get -ENOSPC. Solving the problem by forcing dropping of new data is unacceptable. > But as you said, I doubt the zero-copy is very important (performance-wise) > in this case anyway, so you might just want to stay with your existing > read() interface. Remember that each small junk of your log results from > a relatively slow "syscall tracking", so I doubt the copying of that data > will have a huge impact on the machine's performance. It's our goal to make "syscall tracking" not slow at all. In fact, we want to make get to the point where you can log each and every system call invocation, for every process (!) and stil get reasonable performance from the system. But that's still a long way off, and volunteers are needed (hint, hint :)) -- http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/
msg20519/pgp00000.pgp
Description: PGP signature
