On Thu, 2012-03-08 at 21:03 +0100, Niccolò Belli wrote: > Il 08/03/2012 18:47, Ian Campbell ha scritto: > > There was a breakage of the blktap userspace<-> kernel ABI at one > > point, which might stop 4.1 working with 2.6.32 era kernel wihch might > > also explain this. > > That may be the problem indeed, the only reason Squeeze didn't get > blktap2 was a stupid license issue (stupid because it has been solved > but no one cared reverting the "disable blktap2" commit in debian). > > Unfortunately I don't think backporting blktap-dkms will be an easy task: > > DKMS make.log for blktap-2.0.91 for kernel 2.6.32-5-xen-amd64 (x86_64) > gio 8 mar 2012, 19.48.20, CET > make: Entering directory `/usr/src/linux-headers-2.6.32-5-xen-amd64' > CC [M] /var/lib/dkms/blktap/2.0.91/build/control.o > CC [M] /var/lib/dkms/blktap/2.0.91/build/ring.o > CC [M] /var/lib/dkms/blktap/2.0.91/build/device.o > /var/lib/dkms/blktap/2.0.91/build/device.c: In function > ‘blktap_device_make_request’: > /var/lib/dkms/blktap/2.0.91/build/device.c:212: error: ‘REQ_FLUSH’ > undeclared (first use in this function)
Hrm, that's unfortunate. I suspect it wouldn't be that hard for someone to add the necessary compat #ifdefs etc to allow these modules to build on a variety of kernels (e.g. a diff vs. the 2.6.32 branch from xen.git would give some guidance). Perhaps an alternative solution is to use the blktap driver from the 2.6.32 kernel package but revert 21707:feee0abed6aa from the userspace side, I think (although I'm not 100% sure[0]) that this is the changeset which caused the incompatibility. FWIW the corresponding commit in the xen.git kernel tree seems to be 9ccc03593edcfb70ea846da414d5671952e7e831. BTW, back in <4f5887ce.3050...@gmail.com> you said: Forget about blktap2 in Squeeze... Unfortunately it doesn't work even backporting 4.1.2-3. I should have asked -- what exactly didn't work, what was the failure mode? (I'm wondering if my thoughts about this compatibility issue I mentioned above might have been jumping to a conclusion without sufficient data?) Ian. [0] my memory of the particular issue I'm thinking of is very fuzzy. I've had a look back over the xen-devel archives to see if it jogged my memory, but no luck. > /var/lib/dkms/blktap/2.0.91/build/device.c:212: error: (Each undeclared > identifier is reported only once > /var/lib/dkms/blktap/2.0.91/build/device.c:212: error: for each function > it appears in.) > /var/lib/dkms/blktap/2.0.91/build/device.c: In function > ‘blktap_device_configure’: > /var/lib/dkms/blktap/2.0.91/build/device.c:337: error: implicit > declaration of function ‘blk_queue_max_segments’ > /var/lib/dkms/blktap/2.0.91/build/device.c:345: error: implicit > declaration of function ‘blk_queue_flush’ > /var/lib/dkms/blktap/2.0.91/build/device.c:345: error: ‘REQ_FLUSH’ > undeclared (first use in this function) > /var/lib/dkms/blktap/2.0.91/build/device.c:353: error: ‘struct > queue_limits’ has no member named ‘discard_granularity’ > /var/lib/dkms/blktap/2.0.91/build/device.c:354: error: ‘struct > queue_limits’ has no member named ‘discard_alignment’ > /var/lib/dkms/blktap/2.0.91/build/device.c:355: error: ‘struct > queue_limits’ has no member named ‘discard_zeroes_data’ > /var/lib/dkms/blktap/2.0.91/build/device.c: In function > ‘blktap_device_create’: > /var/lib/dkms/blktap/2.0.91/build/device.c:562: error: ‘struct > queue_limits’ has no member named ‘discard_granularity’ > /var/lib/dkms/blktap/2.0.91/build/device.c:562: error: implicit > declaration of function ‘queue_discard_alignment’ > /var/lib/dkms/blktap/2.0.91/build/device.c:562: error: ‘struct > request_queue’ has no member named ‘flush_flags’ > make[3]: *** [/var/lib/dkms/blktap/2.0.91/build/device.o] Error 1 > make[2]: *** [_module_/var/lib/dkms/blktap/2.0.91/build] Error 2 > make[1]: *** [sub-make] Error 2 > make: *** [all] Error 2 > make: Leaving directory `/usr/src/linux-headers-2.6.32-5-xen-amd64' > > > Niccolò > -- Ian Campbell I prefer the most unjust peace to the most righteous war. -- Cicero Even peace may be purchased at too high a price. -- Poor Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org