Re: [Ndiswrapper-general] thoughts on issues with fedora kernels

[Jim C. <jc...@di...>]

(this is not a flame, and is not directed at anyone)

Id like to suggest that everyone here read these 2 sites regularly.
(this thread particularly, but everyone else too)

http://lwn.net/
http://www.kerneltraffic.org/kernel-traffic/latest.html

many suppositions & speculations are answered there,
with more authority than any of us can toss around.

2nd, the 'get the facts' idea is nice, but I daresay they are aware of
ndiswrapper, and a parade of users asking questions on LKML
(the same ones, over and over again, quite possibly) will just look silly.

3rd, Alans post (thanks for that link) was pretty unambiguous.
code that cant run in 4k stacks is 'already broken'.
AIUI, not all drivers have problems here, Realtek's driver doesnt
(or I havent seen it yet, in my limited use of that card)
We would do well to determine which drivers have this problem,
and collect the info, in one place.  (a wiki perhaps :-O)

4 Kernel development model is changing/changed.
2.7 is still not out, and it may be a while (see KT #291)
http://www.kerneltraffic.org/kernel-traffic/kt20050104_291.html#1

Andrew Morton (one of those authoritative sources) said (speculating):

Or start alternating between stable and flakey releases, so 2.6.11 will 
be a feature release with a 2-month development period and 2.6.12 will 
be a bugfix-only release, with perhaps a 2-week development period, so 
people know that the even-numbered releases are better stabilised.


what Ive read prior is that with more kernel and vendor maturity,
the vendors can be relied upon to keep the unwashed masses stable,
and the kernel is allowed to be more volatile.

FC probly falls in between - its a beta vehicle for Redhat to acid test 
stuff
before it goes to the paying customers (the unwashed masses above)
It may be *as* unstable as vanilla, but unlikely to be *more* unstable,
probably on average less unstable.  Theyre not *trying* to screw with us.

another quote from KT 291

Someone pointed out that Andrew Morton's -mm tree might be bleeding 
edge, but that Andrew made a conscious choice about when to do each 
release, and that this choice probably took stability into account. Alan 
Cox said:

    *

    2.6.x-mm is more like some of the work the old 2.4-ac did in merging
    new stuff (its also worth noting that 2.4-ac ended up more stable
    than 2.4 at times so -mm might be stable)

    The -ac tree is trying to be fairly conservative. When I merge stuff
    that is a little less conservative because it has to be done then
    I've tried to put a note in the relnotes for that release warning
    people its more testing grade.

    *


jeese- theyre all relevant:

Alan Cox announced Linux 2.6.9-ac16, saying:

*

Further small fixes for different minor things. A merge of some of the 
small cleanups from Fedora work and also the fixes for the igmp and vc 
holes.

Arjan van de Ven is now building RPMS of the kernel and those can be 
found in the RPM subdirectory and should be yum-able. Expect the RPMS to 
lag the diff a little as the RPM builds and tests do take time.

*(evidently Gerald has been reading)

5. I cant see 8k kernels going away - ever - if youre willing to build 
your own that is.
theres no runtime cost to a macro define. Of course, if this opinion 
breaks, you get to keep both pieces.

6.  Maybe the best thing we can do is each pony up $5 to buy Giri (or 
his wife)
a nice christmas present.  We certainly have 50 people here. I daresay 
she has more influence over his free time than the demands of the 
bleating flock.