[Stgt-devel] project status

[Tom Tucker]

[...snip...]
> It turned out that we used netlink wrongly so we replaced netlink. We
> need bi-directional, high-speed interface between user and kernel
> space. Currently, there isn't such interface in mainline. So we use
> mapped ring buffer between kernel and user spaces by using own
> character device (I need to replace the very old way to create a
> character device). If we find something better, we will replace the
> current code (netdev guys seems to bring something promising for
> network AIO).

I just looked at this code and am somewhat confused. I understand that
the write handler in the kernel has the user mode process context and
therefore understands any uspace pointer contained in the event. 

What puzzles me is that the write handler in the kernel doesn't use the
passed in buffer, but instead takes the event from an mmaped ring
buffer. It then passes the various fields in the event down to the
handlers as parameters:

	...
		err = scsi_tgt_kspace_exec(ev->u.cmd_rsp.host_no,
					   ev->u.cmd_rsp.cid,
					   ev->u.cmd_rsp.result,
					   ev->u.cmd_rsp.len,
					   ev->u.cmd_rsp.uaddr,
					   ev->u.cmd_rsp.rw);
	...
At this point, you don't need 'ev' anymore (the contents have been
copied into registers as parameters), so I don't understand the need for
the ring buffer. The user space caller could just as well have passed
you a pointer to a local variable in the write system call. Wouldn't
this avoid the complexity of the ring buffer altogether?
	
Are you just trying to avoid the copy_to_user of the ~32 bytes of the
event itself? I'd be surprised if avoiding this copy beats the time
spent managing the ring buffer. 

Sorry if these are a dumb questions...

Tom