MInd that I did not test for this particular application, but usually vmware
incompatibility with recent kernels (actually vmware-config.pl -> compilation of
kernel modules ) is fixed by the any-any patch from
http://platan.vc.cvut.cz/ftp/pub/vmware/. Wouldn't it help here too ?

I asked the vmware guys that very question and they responded that their release
to SoruceForge was essentially 'trunk' from their internal source control, which
includes all the any-any updates.  It appears f8 needs the _next_ any-any update :)

kmod packages? are they allowed still?

Kernel Modules in Fedora have been banned from Fedora, see:
http://bpepple.fedorapeople.org/FESCo-2007-09-13.html 

Search for:
| Proposal: No new kmods, and existing ones dropped by F9.

The easiest way for Fedora to ship these kernel modules is if they are accepted
into the upstream kernel.  Now that the license is acceptable (GPLv2) it should
be possible.  Is it heading upstream?

The more difficult way for Fedora to ship these kernel modules is to convince
the Fedora kernel maintainers that we should.  This is more difficult, because
we generally only accept things that are definitely heading to upstream but not
quite there yet.

Could we ship this as a dkms package ?

(In reply to comment #6)
> Could we ship this as a dkms package ?

No, the only way to include this in Fedora is to persuade the kernel maintainers
to include this module directly in the kernel package.

Here's what Philip Langdale (from VMWare) has to say (he also happens to be the
author of galeon, btw):

> There is a basic acceptance of the principle that we should push them
> upstream but we also know that some of the drivers will require a lot
> of changes or a complete rewrite to get accepted (and vmblock probably
> wouldn't get accepted at all and we'd need to rewrite it using fuse).
> So, given how busy people are, we're being unavoidably vague about
> when this is going to happen.
>
> If you're trying to make an argument for maintaining the modules externally
> for the time being - the big win is having the distro fully functional out
> of the box when installed in a VM - that's what the ubuntu guys are shooting
> for, and I would hope the Fedora guys would want the same thing.

How can we make this work into Fedora ? There are a lot of vmware users out
there, and I think not having open-vm-tools packaged hurts Fedora more that it
helps it. Certainly having it for F-8 would be huge.

This sounds doubtful that it will ever reach upstream.  I recommend pursuing
three parallel tracks on this:

1) Show us that VMWare is making a real effort to eventually get it toward
upstream acceptance.
2) VMWare and davej need to talk about this to see if davej will accept it in
the Fedora kernel in the mean time.
3) Bring this to the next FESCO meeting for discussion.

Re: 2)

Absolutely not.
It's already enough of a battle to get upstream to look at our kernel bugs, and
we aren't that far away from mainline.  Adding stuff that is extremely unlikely
to go upstream is counter-productive to that effort.

This ticket reeks of bureaucracy so bad it's hard to come near it.  First it's
quite annoying that FESCo closed the door on kmods less than a week before I
submitted this pacakge, and they have yet to update the wiki, which I followed
word-for-word making this package.  As far as wiki readers are concerned, there
is still a tried-and-true method to getting kernel modules into Fedora.

I know I'm pleasantly separated from the complexities of kernel maintenance, but
I'm really struggling with how this is different from other packages I maintain.
 As a fedora contributor, I know my upstream packages well and subscribe to all
their {lists|forums|etc}, and more importantly I am willing to put forth any
effort required to keep this packages shipping with Fedora in an operable state.
 I maintain several php-pear and php-pecl packages.  Are you going to argue next
that separate php modules cause needless complexity to I should force jorton to
merge my modules and maintain them himself as part of php.rpm?  He may not know
the modules well or at all.  On top of all that, I am sitting here twiddling my
thumbs ready willing to do the voluntary packaging and maintenance work, why
should I force that work onto somebody else who may not be ready and willing?

What this all comes down to, open-vm-tools is a _HUGE_ new piece of software for
the community.  The ability to install linux in a virtual environment and have 
the guest vm tools come with the distro rocks.  Gentoo has already checked in a
changeset for it, and by Philip's testimony above, Ubuntu is somehow finding a
way through their own red tape to get this working "out of the box".  We all
know RHEL is the big player in the IT server market, but if every other linux
distro on the planet prepackages open-vm-tools except RHEL, that's really going
to hurt its credibility in the ESX community (which I believe is going to
explode in the next [235] years).  I don't care if I package it or the kernel
guys package it, but I'm not wasting my effort convincing the kernel guys to do
it when I'm willing to do it myself.

I'd like to reiterate Denis in Comment #8:
"How can we make this work into Fedora ? There are a lot of vmware users out
there, and I think not having open-vm-tools packaged hurts Fedora more that it
helps it."

I understand your frustration.  You may want to escalate this to the Fedora
Board if you are not satisfied with the rules as decided by FESCO.

Meanwhile you might want to submit the kmod or dkms to Livna so it can be easily
installed for users in the meantime.

Two other issues here:
1) Even prior to this FESCO policy change, it required a case-by-case FESCO
approval for any kmod to get into Fedora.  And that included a requirement that
it was already heading for upstream.  We had outright rejected kmods for
Asterisk hardware due to their refusal to go upstream, while their competitor's
drivers were included because they played by the rules.
2) Even if #1 were not a problem, this is WAY past the feature freeze for F8.

I'd like to point out that (unless I've missed something) FESCo has not 1)
announced that external kernel module packages are now banned in Fedora on
fedora-devel-announce nor 2) even posted the summary of the meeting where this
was decided, so it's not that big of a surprise that people may still be
spending time to package things that do not have a chance to be included.  I've
contacted bpepple earlier today, asking for the announcement.

It is actually kinda sad that Fedora decided to pull dkms kernel module packages
from the repositories because some of those kernel modules are very useful, and
there is no doubt in my mind that Fedora is going to get A LOT of flak for not
finding a way to permit the open-vm-tools into the distribution. Heck, I am mad
myself, because Fedora, my FAVORITE distro, is going to reject one of the
biggest boons to Linux since Xen! It seems that Fedora is losing its ability to
progress and is shooting itself in the foot too many times.... If you really
don't want to support them, simply put the optional kernel modules in a separate
repository, but that is inadvisable. Just allow them in, and better yet, work on
improving them for mainline submission!

There have never been any dkms kernel packages in the repositories, so it is
incorrect to say that anything has been pulled.

Sorry, I meant dkms/kernel module packages... But there used to be packages in
Fedora for them. For instance, kqemu accelerator...

(In reply to comment #8)
> > some of the drivers will require a lot
> > of changes or a complete rewrite to get accepted (and vmblock probably
> > wouldn't get accepted at all and we'd need to rewrite it using fuse).

So it's not actually something we'd have wanted to ship even if we _hadn't_
decided not to allow any more kernel module packages.

The reason we decided not to allow any more kernel module packages is because
this is actually almost always the case. If it's not good enough for upstream,
it's not good enough for us. There are _few_ exceptions, and we've _always_
coped with those by carrying patches in the kernel package.

kqemu has never been shipped in Fedora.  There is at least one third-party
repository which ships a dkms package of it.  For that matter, there has never
been a dmks-based kernel module package in Fedora.  dkms itself is  shipped, of
course.

There have only been two kernel modules shipped in Fedora which are not part of
the kernel package: kmod-em8300 and kmod-sysprof.

(In reply to comment #13)
> I'd like to point out that (unless I've missed something) FESCo has not 1)
> announced that external kernel module packages are now banned in Fedora on
> fedora-devel-announce nor 2) even posted the summary of the meeting where this
> was decided, so it's not that big of a surprise that people may still be
> spending time to package things that do not have a chance to be included.  I've
> contacted bpepple earlier today, asking for the announcement.

 
 AFAIK, FESCO has not yet got their final conclusion. Its not yet made public
whether to ban kernel module or accept them. I think this is second time I am
asking FESCO to make decision in public early(whatever maybe either ban kernel
modules or accept needed kernel modules only).
 I already raised this issue on fedora-devel. If its been unclear to FESCO
itself then people will not stop submitting kernel module packages and same
discussion will get forked again and again whether to accept or ban kernel
modules and which one is good kmod or dkms packaging?

Till posted the IRC log from last week's FESCo meeting in Comment #4 where they
voted 8-1 (Thanks jtibbs, you've got my vote any day of the week) on this very
matter.  I agree with you that the decision hasn't been made public (yet), but
that doesn't mean FESCo is unclear / undecided on the matter.

FESCO,
Am I supposed to look at wikipages for what happened last week's meeting? I
thought its usual way of FESCO to post minutes of meeting on fedora-devel. I
guess If I have not missed any mail I have not seen FESCO meeting minutes got
posted to fedora-devel after 2007-09-06 meeting. How am I supposed to know what
decisions were made in last FESCO meeting?

Brandon,
  Sorry, I missed that comment to read.

Might I ask why you think a comment in a random bugzilla ticket is the proper
way to reach FESCO?

Sure(In reply to comment #22)
> Might I ask why you think a comment in a random bugzilla ticket is the proper
> way to reach FESCO?
> 

Sure. I saw most of peoples related to FESCO and Kernel module packaging are
commenting here. So I took the opportunity to continue the forked (Kernel
modules) discussion.
Do you want me to ask the same(again and again whether kernel modules are banned
or not?) in Fedora-devel mailing list as I can't see any mail on
fedora-devel/fedora-announce saying like that?

(In reply to comment #21)
> FESCO,
> Am I supposed to look at wikipages for what happened last week's meeting? I
> thought its usual way of FESCO to post minutes of meeting on fedora-devel. I
> guess If I have not missed any mail I have not seen FESCO meeting minutes got
> posted to fedora-devel after 2007-09-06 meeting. How am I supposed to know what
> decisions were made in last FESCO meeting?

Normally, I send out a summary for the FESCo meetings, unfortunately I've been
swamped at work the last 2 week and haven't had a chance to write-up a summary
(though the irc logs are available on the wiki).  When I get back home tomorrow,
I should have some free time to work on it.

(in reply to comment #17)
> > some of the drivers will require a lot
> > of changes or a complete rewrite to get accepted (and vmblock probably
> > wouldn't get accepted at all and we'd need to rewrite it using fuse).
>
> So it's not actually something we'd have wanted to ship even if we _hadn't_
> decided not to allow any more kernel module packages.
> 
> The reason we decided not to allow any more kernel module packages is because
> this is actually almost always the case. If it's not good enough for upstream,
> it's not good enough for us. There are _few_ exceptions, and we've _always_
> coped with those by carrying patches in the kernel package.

David, I think that is not a fair assessment. Pushing code to the upstream
kernel is known to be a long and arduous process, and is not always related to
the quality of the code in question, but more about the way it's written, how
it's integrated with other/newer parts of the kernel, and so on.

A prime example I'm familiar with was the Marvell SATA driver: a very high
quality (based on extensive experience) driver, but written straight on top of
the SCSI stuff without using the new libata layer, and as such unpushable
upstream. (a moot example too, Marvell is now working with the upstream
maintainer to port the driver, but these things take time)

I think the things that matter most here are:
 1) is the code stable and high-quality (and well QAed) ?
 2) is the code actively maintained ?
 3) will the code have a large user base ?

I disagree -- I think it _is_ a fair assessment. It's about the quality of the
code and the design -- and that really _should_ be about "the way it's written,
how it's integrated with other/newer parts of the kernel, and so on."

Yes, the bar is high. But with good reason. And the line we tend to take in
Fedora is "if it's not good enough for Linus, we want you to make a _very_ good
case for why you think it's good enough for us".

Remember that we are _not_ just banning all non-upstream code. We've always
carried patches with new drivers &c in our kernel RPM, and now that all packages
are effectively part of "Extras" where the Great Unwashed can get at them, you
have the opportunity to maintain your patch there directly. The only thing
that's different, fundamentally, is that before you had to get an explicit
agreement from FESCo for a kmod package -- and now you have to get an explicit
agreement and commit access from the kernel maintainers instead.

And _if_ your code is deemed good enough to ship, then it's a whole lot nicer
from a technical point of view, because it's not in a separate package with all
the rpm hassle that entails and the requirement for builds to be in lock-step.

On a separate but mostly related note -- at the Kernel Summit a couple of weeks
ago, we spoke about making it easier to merge code which distributions wanted to
ship, and perhaps being slightly less picky about it and more pragmatic. Linus
indicated a desire _not_ to see distributions carrying such patches, like the
wireless-dev tree that Fedora is currently shipping. The idea is that if distros
are going to ship it, we might as well merge it upstream. So merging upstream
_may_ get a little easier too. But there are downsides to that approach on
Linus' part -- because people may stop trying as soon as code is merged, and the
final issues may never get sorted out. We'll see how it works out.

(In reply to comment #25)

> A prime example I'm familiar with was the Marvell SATA driver: a very high
> quality (based on extensive experience) driver, 

Sorry, but either you have no clue or you're a liar.

(In reply to comment #10)
> Re: 2)
> 
> Absolutely not.
> It's already enough of a battle to get upstream to look at our kernel bugs, and
> we aren't that far away from mainline.  Adding stuff that is extremely unlikely
> to go upstream is counter-productive to that effort.

I took a quick look at the filesystem and block driver in the package and
they're a complete nightmare.  Nothing I would recommend people to use at all,
nevermind to package.

Christoph, this is getting off-topic, but we ship mv_sata 3.6.3 with the SunFire
X4500 ("Thumper", 6 88SX controllers, 48 disks). Granted my experience is only
with the 88SX chip series, i cannot speak for other products, and we support
only enterprise kernels, not the latest and greatest. We ship that driver on the
Thumper support CD for very good reasons. We've pushed that driver to its limit
in terms of performance for some of our Thumper-based products, using 12 4-disk
software RAIDs, with hot-swaps etc... Back when Thumper was designed, the kernel
sata_mv driver was not in a usable state yet. It has made much progress since.

If it's just the block driver/filesystem modules that are bad, is it possible to
include a subset of functionality?  For example, "Drag and Drop, Text and File
Copy/Paste" and "Time synchronization", "Automatic guest screen resolution
resizing"?

Looking at http://open-vm-tools.sourceforge.net/faq.php there is a fairly big
list of stuff.

(In reply to comment #30)
> If it's just the block driver/filesystem modules that are bad, is it possible to
> include a subset of functionality?  For example, "Drag and Drop, Text and File
> Copy/Paste" and "Time synchronization", "Automatic guest screen resolution
> resizing"?

I don't think either of these features requires a kernel driver.  I can't easily
spot any routines related to these items at least.

Looks like the vmblock filesystem-lookalike actually is used to implement
cut&paste in some odd way.  Not much of a chance there, sorry.

(In reply to comment #32)
> Looks like the vmblock filesystem-lookalike actually is used to implement
> cut&paste in some odd way.  Not much of a chance there, sorry.

Yeah, it's used to handle both copy/paste and DnD. See
http://sourceforge.net/mailarchive/message.php?msg_name=46E6FDEC.3090700%40codemonkey.ws.

Christoph, since we do want to upstream our kernel modules, could you give us an
idea of what needs to change? Obviously we have to adapt the modules to the
kernel coding style and cut out the older kernel compatibility code, but what
else needs to be reimplemented or redesigned?

A better forum for kernel code review is probably the kernel-mentors list, or
linux-kernel rather than bugzilla.

[Blargh, I need to get my fedorabugs access set up so I can close this myself.
:] Given the Fedora policy, and the impossibility of complying with it just yet,
it seems like this bug should be closed for now. And it's clear that there's
more communication that needs to happen in general about the purpose behind and
implementation of the modules, before they go upstream (thanks for the pointer
to kernel-mentors, Dave).

(Can anyone suggest a preferred "fringe" repository to try getting this package
into in the meantime, so that users that really want the modules can get them?
ATrpms/DAG/Dries/FreshRPMS/NewRPMS/Livna?)

Elliot, I've closed the bug for you, I hope you agree on the resolution.
I would have suggested rpmfusion as alternate repo, but since the review rules
are mostly the same, I am not sure it can be included over there, either.

(In reply to comment #36)
>
> I would have suggested rpmfusion as alternate repo, but since the review rules
> are mostly the same, I am not sure it can be included over there, either.

The "mostly" here is the point; packages with kernel modules will be allowed in
rpmfusion, but we are not 100% sure yet how to package them. A mix/combination
of kmods and dkms seems likely to me ATM. 

But rpmfusion needs to get it's infra running first before we take care of that
problem.

In addition: livna will of course take the kmods and from there we'll make it
easy to move them to rpmfusion later.

Submitted to livna

The fact that Fedora takes a "Kernel upstream won't talk to us if we have bugs in tainted kernel, so we don't ship kernel mods" stance is the big blocker here.

In essence, it's a matter of user choice.  RMS will say this is great and fine, because users can just decide that Fedora is crap and fork it, because GPL.  Sensible people will realize 1) forking something huge like Fedora is nutty; 2) add-on repos (RPMForge) are simpler; and 3) "Fedora is crap" is the ultimate bug.

More to (3), re 'user choice', the Fedora developers aren't shipping kernel module packages or dkms for users to electively add on.  I fully support Dave Jones in his idealism of a perfect, pristine, untainted main kernel package.  A base vanilla package I would support in any distro, with whatever kernel patches (yeah every distribution has a pile...) in a different kernel package.  I don't mind very-vanilla.

I think better would be a hard-line policy that additional kernel modules 1) must not modify the kernel tree; and 2) must ship as separate packages.  The user can always subvert "No External Modules" with a compiler, and what then?  "Well that's not supported?"  You could always mark external modules as "At your own risk" as policy--because face it, resources are limited and not everyone can approach kernel issues.