Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow

Eric Rostetter rostetter at mail.utexas.edu
Sat Jul 3 03:39:02 UTC 2004


Quoting Jon Peatfield <J.S.Peatfield at damtp.cam.ac.uk>:

> Maybe now would be a good time to start thinking about moving (in a
> few months maybe) to a kernel tree based on 2.4.26/27pre just to
> reduce the total number of overlapping patches.

Unless we find that patch conflicts are causing build/maintenance
problems for us, I don't see this as a positive move.

> Now that 2.4 is firmly in "maintenance mode" there won't be any new
> features added so it should be possible to remove a great number of
> the existing patches just by using a more modern starting point.

While new features won't be added now, have they already been added
between our starting point and now? If so, it kind of goes against
our policy, unless it facilitates our continued support of the kernel.

> Of course without understanding what _all_ of the patches are doing it
> is always a bit risky to decide which would still need to stay or be
> changed to be relevant against 2.4.26/27...

Sounds like maybe we don't need to take that risk...

So, unless we have problems with conflicting patches, I'd say stay with
what we have.

If we go newer than RHEL 3, then our job becomes tougher as we can't take
advantage of Red Hat's patches.  Staying with our base, or moving only to
the RHEL 3 version, gives us 3 years of using RHEL as an aide to our patches.
Going newer means we would be on our own much more often...

--
Eric Rostetter





More information about the fedora-legacy-list mailing list