[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |