On Sat, 2010-12-18 at 18:23 +0100, Julien BLACHE wrote: > 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.
Actually it does. The ABI change was part of a stable update. > > 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. That is probably copyright infringement. > >> 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 sounds like you should really be using ESX/vSphere on the host, rather than VMware Server on Debian. I mean, VMware Server is basically demo-ware. > > 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. Where are your bug reports on nouveau? > 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. Binary-only drivers for Linux are generally copyright infringements. If we break them: good. (I know nvidia provides a Linux-specific stub as source and it might be an exception to this.) > I'm pretty disappointed by the way you're handling this; it feels like > you have little care for what your users actually need. We do, just not all of what *you* (one of our users) want. Ben. > 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. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
