On Sat, 2007-09-08 at 17:22 -0400, Lamar Owen wrote:
> On Saturday 08 September 2007, Matthew Saltzman wrote:
> > On Sat, 2007-09-08 at 15:22 -0500, Les Mikesell wrote:
> > > I want a stable kernel and device drivers. The unix-like system call
> > > interface doesn't need to change every week.
>
> > You've used similar phrases a few times in this and related threads, and
> > it prompts a question:
>
> > Is this hyperbole, or are you really suggesting that every time a new
> > kernel install requires a recompile of an external driver or binary
> > driver shim, that it's because the API has changed?
>
> Run VMware workstation on a Fedora machine, going through the kernel updates,
> and then get back to me (or VMware server, it has the same problems). And
> the problem isn't with the binary parts; it is with the open-source parts. I
> shouldn't have to recompile stuff every kernel revision.
I do run VMware (and the NVidia drivers). I'm not a kernel internals
expert by any means, but the recompiles necessary to make the modules
available for new kernels seem to me likely to be due either to that
being the most straightforward means to get the modules that aren't
distributed with the kerenl (such as the OSS parts of proprietary
modules) in the right place on the disk to be loaded, or maybe because
some addresses or parameters that the kernel exports change routinely.
If it's the latter, then perhaps that could be handled differently. The
experiment would be to copy the old module to the new /lib/modules tree
and see if it worked.
But that's still not the same as requiring source changes, as you
discuss below. That seems to me to be a different class of breakage,
and it doesn't happen within updates to a single kernel version.
>
> The short of it: even Linus will admit that the 2.6 kernel series is not
> stable between versions; not only does he admit it, but he likes it and
> thinks it is a good thing. Not only does the binary interface change, the
> source interface changes. Go to the vmware forums and search
> on 'vmware-any-any' and read the threads.
Been there.
>
> It's not limited to Fedora, either; Ubuntu does the same thing. It's an
> upstream (kernel) disease that has decreed that ABI and API compatibility is
> not important between new versions.
>
> So between 2.6.19 and 2.6.20 a source patch had to be made to the open-source
> portions of vmware workstation (and vmware server) to get it to even compile;
> between 2.6.20 and 2.6.21 the same thing. Between 2.6.21 and 2.6.22 the same
> thing. It's bad enough to have to recompile every time a new kernel is
> sucked in by yum; it's worse when you have to track down what has changed and
> how to patch the vmware source to be able to recompile. I just track the
> vmware-any-any patches and stay a week or so behind on kernel updates; I
> don't have time to dig into the kernel changelog to see what they changed
> this week. And, of course, I only run Fedora 7 on development
> desktops/laptops; the servers get CentOS, not Fedora, and production desktops
> get something else.
Same here.
>
> I want the same thing Les wants: a stable kernel and newer, frequently updated
There certainly are reasons to want development to proceed on kernel
technology and drivers. The state of wireless drivers in Linux is just
sad, for example. Getting new drivers that support wext correctly and
improve performance and functionality is a worthy goal, even for older
hardware. Other drivers may add functionality for hardware that was
only partially supported before. Some regressions are inevitable in
those cases. (It would be nice if it weren't so.)
Nevertheless, I understand the goal and why Fedora is frustrating if
that's what you want.
> userland. The CentOS Plus repo begins to get it; for KDE stuff KDE-Redhat
> installed on CentOS gets it. In fact, KDE-Redhat on a CentOS base is just
> about ideal, if you use KDE (and I do); this is what I put on my production
> desktops that run Linux.
Also see the new EPEL repository, where Fedora developers build RHEL
versions of Fedora packages. And of course, several independent repos,
such as ATRPMs and RPMforge.
>
> Incidentally, Les is quite active over on the CentOS lists, so, he's well
> aware of that option.
>
> Oh, just in case you are wondering about my 'history' check out the changelog
> for the PostgreSQL RPM's prior to version 8.0.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
