this patchset replaces the 1990s-era memory allocation tracking
with a 2010s-era memory allocation tracking. Particularly, it
removes the neccessity to maintain a centralised list of MTYPEs
in the library. Daemons can now just define their own MTYPEs on
the fly, with per-file static scope even
This places MTYPE definitions into the files where they're actually
used, making most of them static in the process.
Signed-off-by: David Lamparter
---
lib/buffer.c | 3 ++-
lib/command.c | 4
lib/command.h | 6 +
lib/distribute.c | 3 +++
lib/filter.c | 4
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.
Signed-o
Move over to the new allocation counting added in the previous commit.
(This commit is mostly mechanical.)
Signed-off-by: David Lamparter
---
bgpd/bgp_main.c | 1 +
bgpd/bgp_vty.c | 1 +
isisd/isis_main.c | 1 +
isisd/isis_redist.c | 1 -
lib/M
Signed-off-by: David Lamparter
---
lib/.gitignore | 1 -
lib/Makefile.am | 10 +++---
lib/memtypes.c | 16
lib/memtypes.pl | 6 --
4 files changed, 3 insertions(+), 30 deletions(-)
delete mode 100644 lib/memtypes.c
delete mode 100755 lib/memtypes.pl
diff --git a/li
Signed-off-by: David Lamparter
---
INSTALL.quagga.txt | 1 -
configure.ac | 6 --
2 files changed, 7 deletions(-)
diff --git a/INSTALL.quagga.txt b/INSTALL.quagga.txt
index 11c85b1..b414d94 100644
--- a/INSTALL.quagga.txt
+++ b/INSTALL.quagga.txt
@@ -69,7 +69,6 @@ deficient is made.
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
---
bgpd/bgp_nexthop.c | 8 +---
isisd/isis_memory.c | 2 +
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
---
lib/Makefile.am
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
---
A few places are using 0 in place of the MTYPE_* argument. The
following rewrite of the alloc tracking won't deal with that, so let's
use MTYPE_TMP instead.
Signed-off-by: David Lamparter
---
lib/prefix.c| 2 +-
ospfclient/ospf_apiclient.h | 2 +-
ospfd/ospf_opaque.c |
Hi quagga-dev,
this patchset replaces the 1990s-era memory allocation tracking
with a 2010s-era memory allocation tracking. Particularly, it
removes the neccessity to maintain a centralised list of MTYPEs
in the library. Daemons can now just define their own MTYPEs on
the fly, with per-file sta
The following commit will recreate memory.[ch].
Signed-off-by: David Lamparter
---
lib/Makefile.am | 8 +-
lib/memory.c | 486 ---
lib/memory.h | 98 +--
lib/memory_vty.c | 486 +++
Ok, false alert.
Lovely CI system picks random execution nodes during the git bisect
and one of the node had a stuck route - so by random it happened
to end up with this specific commit as “bad”
Looks like nothing wrong here.
(And now back to re-testing with fixed CI cleanup procedure)
Sorry.
Argh!!
Found an issue - partially my mistake: I’m not rebooting the DUT
between runs (Just uninstall/reinstall quagga and
restart it with clean config). This only applies to my CI automated run
- not the PDF compliance report.
(I build new machines from scratch in that test for each run)
So w
So, here is puzzle someone might have a hint.
Both of these are tested with the SAME FreeBSD package. Both are
installed on
basically the same DUT FreeBSD (cloned from the same master).
Both are based on the git commit 04a3aabf58d95 (which is the candidate
for
the bad commit identified earlie
Donald,
give me a few more hours to narrow the issue down. Still have a few more
ideas
to correctly replicate this.
At this time, I worry you would not be able to reproduce the issue and
just
waste your time.
(Getting the config.log from the port build isn’t that trivial)
For hints on how I
Martin -
Can I see the config.h and config.log generated for your test?
thanks!
donald
On Tue, Feb 23, 2016 at 4:15 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:
> On 23 Feb 2016, at 5:23, Donald Sharp wrote:
>
> Martin -
>>
>> What's your configure line for freebsd? Can you point
On 23 Feb 2016, at 4:55, Donald Sharp wrote:
Vincent/Nicholas -
Can we get some help tracking down and fixing this issue?
Main issue would be to have a critical look at this patch in regards
to FreeBSD and see if something could be wrong for FreeBSD
(FreeBSD 10.2 is what I test)
It would be i
On 23 Feb 2016, at 5:23, Donald Sharp wrote:
Martin -
What's your configure line for freebsd? Can you point me at your
config.log for this build? My freebsd vm is unhappy with me right
now.
That’s where I have issues. My CI integrated system spots the error
(and every time), but if
I try
On 2/23/2016 10:24 AM, Paul Jakma wrote:
> On Tue, 23 Feb 2016, Paul Jakma wrote:
>
>> We havn't though had much of a problem with people adding notices when they
>> shouldn't though. The problem is more the reverse.
> Oh, and my desire is for people to be clear, explicit, unambiguous and
> com
Paul,
On 2/23/2016 10:18 AM, Paul Jakma wrote:
> On Tue, 23 Feb 2016, Lou Berger wrote:
>
>> Paul,
>>The link you provide is quite informative -- although I'm a bit
>> worried about encroaching on armchair lawyering .
> Ack, indeed. Best rely on best-practice docs and advice as much as
> pos
On Tue, 23 Feb 2016, Paul Jakma wrote:
We havn't though had much of a problem with people adding notices when they
shouldn't though. The problem is more the reverse.
Oh, and my desire is for people to be clear, explicit, unambiguous and
complete in describing the rights interests in any contr
On Tue, 23 Feb 2016, Lou Berger wrote:
Paul,
The link you provide is quite informative -- although I'm a bit
worried about encroaching on armchair lawyering .
Ack, indeed. Best rely on best-practice docs and advice as much as
possible.
From that link:
Not every contribution to a f
Paul,
The link you provide is quite informative -- although I'm a bit
worried about encroaching on armchair lawyering .
>From that link:
> Not every contribution to a free software project is copyrightable
> Since copyright notices are not mandatory, there is generally no harm in
> under-usi
Martin -
What's your configure line for freebsd? Can you point me at your
config.log for this build? My freebsd vm is unhappy with me right now.
donald
On Mon, Feb 22, 2016 at 10:26 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:
> On 22 Feb 2016, at 6:40, Donald Sharp wrote:
>
> Ma
Do we forsee a future where we modify this behavior of assert? If so then
I would make it a requirement of the person doing that work to go and fix
all assert code. I'm not sure I want to worry about this at this point in
time.
So this 'hack' to make the compiler happy is ok with me.
donald
On
I tried to be very vague in what constitutes a major -vs- minor for just
the reasons you outlined. I wanted the person doing the work to have some
flexibility to apply some brain cells for what is right. If we can agree
that we have brain cells and that we can use them I think I'm ok with
leaving
Vincent/Nicholas -
Can we get some help tracking down and fixing this issue?
thanks!
donald
On Mon, Feb 22, 2016 at 10:26 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:
> On 22 Feb 2016, at 6:40, Donald Sharp wrote:
>
> Martin -
>>
>> Any word on this? I'd like to push this patch i
On Tue, 16 Feb 2016, Donald Sharp wrote:
In today's Monthly meeting we briefly discussed how we would like to
version Quagga going forward. Two proposals were put forward, a date based
version string or a Major.Minor.Bug version string. I'd like to propose
that we combine the two of them toget
On Mon, 22 Feb 2016, Lou Berger wrote:
Hi,
The following caught my eye:
https://lists.quagga.net/pipermail/quagga-dev/2016-January/014686.html
+ at c Copyright @copyright{} 2015 Hewlett Packard Enterprise
Development LP
Which lead me to finding http://patchwork.quagga.net/patch/1800/ aka
h
30 matches
Mail list logo
