Move over to the new allocation counting added in the previous commit.
(This commit is mostly mechanical.)
Signed-off-by: David Lamparter
Acked-by: Vincent JARDIN
---
bgpd/bgp_main.c | 1 +
bgpd/bgp_vty.c |
This is a rather large mechanical commit that splits up the memory types
defined in lib/memtypes.c and distributes them into *_memory.[ch] files
in the individual daemons.
The zebra change is slightly annoying because there is no nice place to
put the #include "zebra_memory.h" statement.
The following commit will recreate memory.[ch].
Signed-off-by: David Lamparter
Acked-by: Vincent JARDIN
Acked-by: Donald Sharp
---
lib/Makefile.am | 8 +-
lib/memory.c | 486
Signed-off-by: David Lamparter
Acked-by: Vincent JARDIN
Acked-by: Donald Sharp
---
lib/.gitignore | 1 -
lib/Makefile.am | 10 +++---
lib/memtypes.c | 16
lib/memtypes.pl | 6 --
4
Signed-off-by: David Lamparter
Acked-by: Vincent JARDIN
Acked-by: Donald Sharp
---
INSTALL.quagga.txt | 1 -
configure.ac | 6 --
2 files changed, 7 deletions(-)
diff --git a/INSTALL.quagga.txt
Hi all,
this is the rebased version of this series, now applying on
ca52365 "FreeBSD Bug: Zebra not deleting routes"
I've also removed the "#if 0" macro branch and fixed remaining
coding style issues I could find.
As these changes are whitespace to the C compiler, I've taken the
liberty of
This rewrites Quagga's memory per-type allocation counting, without
using a fixed global list of types. Instead, source files can declare
memory types which get handled through constructor functions called by
the dynamic linker during startup.
Signed-off-by: David Lamparter
bgpd, ospf6d, isisd and some tests were reusing MTYPEs defined in the
library for its own use. This is bad practice and will break with the
later commit making the library's MTYPEs static.
Signed-off-by: David Lamparter
Acked-by: Vincent JARDIN
This adapts the dump-at-exit handler and removes the old leftover code.
(Note the text in log_memtype_stderr was actually incorrect as the only
caller in bgpd cleans up configuration before calling it, i.e. any
remaining allocations are missing-cleanup bugs.)
Signed-off-by: David Lamparter
Paul,
On 02/25/2016 07:49 AM, Paul Jakma wrote:
> On Thu, 25 Feb 2016, Lou Berger wrote:
>
>> Paul,
>> I think you and I are getting close to some agreeable text . At this
>> point I think it would be good to hear from others particularly from
>> those who contribute most significantly to the
On Thu, 25 Feb 2016, Lou Berger wrote:
Paul,
I think you and I are getting close to some agreeable text . At this point I
think it would be good to hear from others particularly from those who
contribute most significantly to the project at this time. See below for
specific responses.
Ack,
David -
As a heads up, after we get the current proposed/6/ff into main and a new
release released, I intend to start working in the cumulus take-3 branch
on the next iteration of work. If you would like to rebase to there, I
would be willing to help you do that.
donald
On Wed, Feb 24, 2016
When examining performance information it is nice to not
have to look at daemons who you are not interested in.
Signed-off-by: Donald Sharp
Reviewed-by: Don Slice
---
vtysh/vtysh.c | 44 +++-
1 file
Paul,
I think you and I are getting close to some agreeable text . At this point
I think it would be good to hear from others particularly from those who
contribute most significantly to the project at this time. See below for
specific responses.
On February 24, 2016 4:26:28 AM Paul Jakma
Hi,
So, "cute" widely means "attractive". In British Isles use at least and
possibly more pronouncedly so in Hiberno-English, it further can be used
to mean "clever" (see also the references to intellect for the
definition of 'acute'). Often combined with a mild male-ish pejorative
(e.g.,
15 matches
Mail list logo