Bug#607368: Kernel ABI management
Ben Hutchings <ben@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 <jblache@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
Reply to: