Wed Feb 23 14:35:25 PST 2005
On Wed, Feb 23, 2005 at 01:53:27PM -0800, J. Paul Reed wrote:
> On 23 Feb 2005 at 09:00:38, Greg KH arranged the bits on my disk to say:
> > > Ahh... and Xen is different how? Oh right... they just modify the whole
> > > damn kernel (and require you to patch your entire kernel every rev).
> > No, Xen is going to make it into the mainline kernel soon, and then no
> > patching will be needed. When will vmware achieve this goal? :)
> Everyone is saying "Xen is going to be in the mainline kernel; no, really!"
> I'm not disputing this fact, but I'll believe it when I see it. Right now,
> it's vaporware. And a really crappy argument.
But it can happen, right? And it _never_ will happen with the current
vmware modules, right? That's my point.
No, my main point was that people are trying to work toward a common
virtual device layer, so that there is no need for vmware modules in the
future. You seem to dispute this fact. Other people at vmware would
disagree with you.
> > No, I complain as the vmware module taints my kenel, requires a separate
> > step to build from my normal kernel build process, and if I load it into
> > my kernel, I invalidate any and all support contracts I might have paid
> > for, and I can no longer ask for help with any kernel problems from
> > anyone in the open source kernel community.
> Some people actually want to use their Linux box to do useful things. If
> you want to have the "purity" argument, go troll some Debian lists.
> Me, I have no problem with a module that taints my kernel, especially when
> I have source for it.
But real life customers do care about this, as it breaks their service
contracts. I'm not talking "purity" here, I'm talking big money.
And "have the source" is quite different from "open source", as you well
know. Look at the top of the vmware kernel modules. That explicitly
states that that code is not "open source" in any form of the word.
> And with any other product, you can get support from VMware; they did,
> after all, write it, and support is available. It's pretty good, to hear
> other people talk about it, too.
That's great. It just invalidates other service contracts at the same
time, which, from what I have seen, is not obvious to the user when they
purchase the product.
But hey, I don't really care about this issue, so I'm not going to argue
the point anymore.
> It's the Service Console.
Ah, nice, thanks for the info.
> It is not used for any of the things you mention.
> In some sense, it's a glorified boot loader.
So it controls access to the hardware under the esx os? Where does the
actual, write the bits out to the scsi controller happen from? Each
> > I just don't like the fact that their kernel modules are not included in
> > the main kernel tree. I view Linux closed source modules as derivative
> > works, and feel they should be required to be released under the GPL. I
> > know a lot of IP lawyers who also feel the same way. See my, and other
> > kernel developers effort to help fix this issue in the recent kernel
> > releases (marking non-needed functions static, use of EXPORT_SYMBOL_GPL,
> > etc.)
> Except uhh... they're not closed source. You're whining about the binary
> pre-built modules.
They are closed source, see above.
> Don't want to use them? Compile your own modules; you have to do that
> anyway if you're running a kernel version that doesn't have binary
> pre-built modules. (And since you have to compile them yourself... uhh...
> there's source code there.)
> So I really don't know what you're whining about.
I'm complaining about the fact that the vmware modules will never be in
the main kernel tree. And because of that, they are a leach on the
kernel development process. They take from our development effort and
give nothing back.
> > I also begrudge the fact that the amount of development effort that
> > vmware gives back to the kernel community is pretty much non-existant,
> > in comparison to everything they are taking from it. But for more
> > details on that topic, see my OLS paper for this year...
> What else would you like them to do?
Work together with other groups to get a common virtual device driver in
the kernel that everyone can use. Barring that, move their existing
drivers into the mainline kernel tree. Give something back to the
community, as it is, they are not giving anything.
Now to be fair, they don't _have_ to do so. It's just not the nicest
stance to be taking if you think about where Linux came from.
> They a) obviously don't take as much as you think they do; you're clearly
> just plain wrong about what their "bread and butter" product actually is,
> so they're not "stealing" what you think they are and b) they release all
> of the changes they make to GPL software (see the tarball you link to
> above), exactly as the GPL requires.
Their kernel modules are not licensed under the GPL. That is not legal
as per the GPL. Now I'm not going to get into the whole "Linus made an
exception for kernel modules" argument, as that:
- was for old drivers that were written before Linux existed.
- necessary for connectivity to legacy systems that Linux users
wanted to connect to (like AFS).
- has been withdrawn in the past few years by Linus himself, and
explicit stated that it is _not_ what a number of core kernel
developers want to have happen to their code.
Remember, loading a module into the kernel is "linking." See the GPL
for what that means you have to do with your code if you link.
> They also happen to support open source projects like Mozilla and Samba.
Great, good for them. Again, why can't they do the same for the kernel?
> So... why exactly are you complaining again?
Closed source leaches. That's why :)
More information about the linux-elitists