[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH] make protocol specific usage of shared sring explicit



On Thu, 2010-07-01 at 10:22 +0100, Ian Campbell wrote:
> I don't think protocol specific data't really belongs in this header
> but since it is already there and we seem to be stuck with it lets at
> least make the users explicit lest people get caught out by future new
> fields moving the pad field around.

The blktap use of the pad field was/is used as a back channel of sorts
to communicate device shutdown from the toolstack to the userspace
tapdisk process via a sysfs write which set the flag in pad[0] which the
tapdisk userspace picked up. This has now been replaced by a unix domain
socket control interface (tap-ctl) allowing communication directly
between the toolstack and the tapdisk process (a much cleaner and
preferable interface). 

However the interface between userspace and kernel was inadvertently
changed when the netfront smartpoll feature was added to netback due to
the new field in the shared ring which caused the the poll[0] field to
move up by one in the structure.

On the kernel side smartpoll change was apparently merged into
xen/master in October 2009 and on the hypervisor side the it is present
in Xen 4.0. So it seems that we have combinations in the wild of kernel
blktap and tapdisk userspace both independently using one of two
possible offsets of pad[0].

Perhaps this interface would be better deprecated and removed sooner
rather than later? Is the tap-ctl baked enough to consider for Xen
4.0.1?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.