----- Original Message -----
From: "Guy T. Rice" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 23, 2000 12:54 PM
Subject: Re: [Cooker] Re: kernel RPMS are not providing "kernel"
> On Wed, 23 Feb 2000, Jeff Garzik wrote:
> > Chmouel Boudjnah wrote:
> > > > I also want to bring up again the problem with kernel-2.2.15-0.7mdk
not
> > > > properly exporting best_memset for some reason. I had to revert to
the
> > > > 2.2.14 kernel to get vmware working. One of it's kernel modules
> > > > complains about best_memset not being available on the 2.2.15
kernel.
> > >
> > > ask this on the lmkml but not sure if they will not reject you by a :
> > >
> > > we don't support binary drivers
> >
> > Yep... if a binary driver works for you it is basically luck (and maybe
> > good testing by the vendor). Binary modules depend on basic things like
> > sizes of types not changing, sizes of core structures not changing,
> > etc. Both kernel and compiler options used at the time of the kernel
> > build affect these variables. In order to completely support a _single_
> > distro, a VMWare (for example) needs to provide a binary module for
> >
> > * kernel-linus
> > * kernel-fb
> > * kernel
> > * kernel-smp
> > * kernel-smp-fb
> > * kernel-your-flavor-of-the-month
> >
> > ...and also provide custom builds for people with highmem/non-highmem
> > cconfigurations, etc.
> >
> > For MandrakeSoft, I think it is MOSTLY the same situation. But since we
> > are a vendor, we can make "quick hacks" if they are safe and get some
> > binary modules working.
> >
> > So... I think exporting "best_memset" from all our kernels is a safe
> > and good patch...
>
> It should be noted that this isn't a "binary module" problem. When VMware
> installs, it _compiles_ new modules to go with your existing kernel,
unless
> you have one it knows about (i.e. you're running genuine and unmodified
> RedHat). You get the best_memset error when attempting to load the new
> module you just compiled!
>
> I had this error come up before while using the 2.2.14pre kernels, and had
> to revert to 2.2.13. When 2.2.14 was officially released, the problem
went
> away. Based on what the poster above is saying, it sounds like the
problem
> has reappeared in 2.2.15pre again. Odd as this sounds, it seems like the
> problem always and only occurs with "pre" kernels.
>
