Ben Hutchings <b...@decadent.org.uk> wrote: Hi Ben,
>> This is reinforced by reading the packaging scripts and realizing they >> check the whole ABI, prior to -28. > > This is not correct. We have ignored many changes since 2.6.32-12 when > the ABI number was bumped to 5. In 2.6.32-27 the symbol version files > were refreshed and the ignore list was reset. This is even more troubling. > The upstream policy is that symbol exports may be removed when there are > no in-tree users. So that export could even be made conditional on > CONFIG_KVM_MODULE (or whatever it's called). Upstream policy doesn't break your setup from one kernel package revision to the other. > Maybe I should find a way to limit that export so OOT users won't make > this mistake. Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL() and people still do work around that. >> See the top of this mail where you state that no list of symbols covered >> by the ABI was ever published for Debian kernels. It isn't unreasonable >> under these circumstances to assume that all symbols are covered. > > It is extremely stupid. We obviously disagree. >> VMware, nVidia, various drivers and infrastructure for communications >> hardware (been there, done that), ... > > VMware - use KVM. Not possible. We require 3D pass-through that KVM doesn't offer. Windows virtio drivers failed us on Vista/Seven (can't remember, not my area), plain old IDE emulation is too slow to be usable. Also, issues with moving a VM from one host to another from a Windows licensing standpoint (still researching this one, though). It's not that using KVM wouldn't ease our (and our user's) life considerably, it's that we *cannot* use it, and there are real reasons why we cannot (and I'm not even speaking of getting that solution approved internally, it's really a detail given the above). As you can see on my blog, I'm the one responsible for packaging VMware. My life would be better if we could just use KVM, believe me. Packaging VMware 7 was a nightmare. > nvidia - use nouveau, report a bug if it doesn't work. Doesn't work with our cards, not by a long shot. Probably won't work for another decade or so, so not an option. We do need working and fast 3D. Switching to AMD - oh yeah, we tried that. I have a drawer full of test cards. Not a single one has working 3D with free drivers, and here again it won't happen for another year or two *best case*. Not an option. Once again: not that we wouldn't like to use free drivers, but we just can't. And I'm the one backporting and testing the nVidia drivers, so believe me when I tell you I'd be using Nouveau if it was an option. We are limited by our user's requirements on the one hand and by what hardware vendors can sell us on the other hand - and they can't sell us yesteryear's tech forever, especially on high-end mobile workstations. Anybody doing this type of large-scale deployment faces the same issues. > random drivers - send them to the maintainer of crap (Greg K-H, for the > staging tree). :-) That being said, not every out of tree driver comes with source. Although pure crap has made it to staging in the past, I'm pretty sure multi-megabyte binary blobs don't stand a chance. I'm pretty disappointed by the way you're handling this; it feels like you have little care for what your users actually need. I find it a bit sad, given all the very good work you've been doing with the kernel otherwise. As I wrote already, it's not like VMware is some obscure piece of software that nobody knows about. JB. -- Julien BLACHE <jbla...@debian.org> | Debian, because code matters more Debian & GNU/Linux Developer | <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zks3dmgn....@sonic.technologeek.org
