[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New tools and 188.8.131.52
- Date: Tue, 02 May 2006 22:01:00 +0200
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: New tools and 184.108.40.206
On Tue, 2006-05-02 at 11:57 +1100, Steven Johnson wrote:
> Joel Sherrill wrote:
> > Steven Johnson wrote:
> >> Ralf Corsepius wrote:
> >>>> Neither of which are useful for me. I already use zlib 1.2.3 and
> >>>> my zlib is customized, so i cant have both of these.
> >>> Any particular reason for doing so?
> >> Well, yes. Zlib 1.2.3 is bug fixed. Also, we have patched it so it
> >> returns us status information through a decompress operation so we can
> >> show the progress of long unzip's, which the library doesnt do
> >> normally.
> > Then the zlib in RTEMS needs to be updated.
> This may be so, but the difficulty here will be unless a new version of
> rtems is released every time a new version of zlib is released,
Only security sensitive changes and major bug fixes to zlib are of
relevance. Anything else is versionitis.
> will always be times when the version in rtems isn't the latest.
Yes, ... and, where is the problem?
The zlib version
... in GCC won't be the latest, either, nor will others be.
... nor will the networking stack in RTEMS be in sync with that in
... nor will your development's machine's zlib be in sync with "bleeding
There is no reason for always wanting to use the "latest version"
> I don't think my patches would be very acceptable to the zlib
> maintainers, because they introduce a measurable net decrease in
> decompress speed, which for us is acceptable, but in the main people
> seem to want a zlib thats as fast as possible. We put up with the
> decrease because it means we get feedback during the ~8-10 minutes it
> takes to decompress, whereas without it, we get no feedback and it takes
> ~7-9 minutes to decompress.
Then YOU have a system integration problem
> > With that said, I don't see too much trouble with an option to disable
> > zlib and pick up another version.
Please implement this yourself - I guess you both still have not
understood how much depends on zlib:
It's the whole network stack, not only pppd, and it is being used by
bootloaders and many other useful tools and components.